CC @griesemer

There was some discussion of this in the thread starting at https://groups.google.com/g/golang-nuts/c/iAD0NBz3DYw/m/VcXSK55XAwAJ which led to that part of the proposal being withdrawn. CC @rogpeppe

I think it's probably too late to add this to 1.18 at this point.

This thread seems to be referring to type switching on the constraint, not on a value with a generic type. I was assuming type switching on a value but being able to treat it as the final concrete type because only the correct branch would be compiled in and at this point there is no uncertainty about what type the value is. It's possible I misunderstood this about the original FAQ in the proposal as well. For example, I'd like to be able to do something like the following and have it work (with the type switch reduced to just the correct line at compile time):

type foo struct {
	foo string
}

type bar struct {
	bar string
}

func printFooOrBar[T foo | bar](v T) {
	switch t := v.(type) {
	case foo:
		fmt.Println(foo.foo)
	case bar:
		fmt.Println(bar.bar)
	}
}

func main() {
	printFooOrBar(foo{"foo"})
	printFooOrBar(bar{"foo"})
}

It's possible this would need some different syntax (.[type]?) to distinguish it from the case where v is indeed a runtime interface though, otherwise it can be hard to tell what's happening at a glance.

I was assuming type switching on a value but being able to treat it as the final concrete type because only the correct branch would be compiled in and at this point there is no uncertainty about what type the value is

Hi @SamWhited, is there some overlap with what you wrote in that quote with #45380? (And I happen to like this earlier example in #45346 (comment)).

I don't see any particular reason why a type switch on a generic value couldn't be allowed (although the "reduced to just the correct line at compile time" aspect is an implementation detail and probably wouldn't be the case with the current GC-shape stenciling implementation).

I'm biased of course, but I think that #45380 provides a nicer and more generally useful facility. For example, if printFooOrBar returned a value of type T it wouldn't be possible to return t without a type assertion, even if this proposal were accepted.

is there some overlap with what you wrote in that quote with #45380?

Yes, that looks the same. Thanks for the link!

although the "reduced to just the correct line at compile time" aspect is an implementation detail

Yes, that's definitely the case.

Placed on hold.
— rsc for the proposal review group

Really we want to examine the type parameter though, not the variable, right?. Perhaps it would be more useful if we switched on the type parameter itself.

switch T.(type) {
case rune:
    ...
case ~string:
    ...
case int, uint:
    ...
}

Perhaps it would be more useful if we switched on the type parameter itself.

That's exactly what #45380 proposes.

Not sure if this specific use case is part of a proposal (the issue trackers are a bit tricky to search through sometimes), but.

Say I have these type constraints:

type SignedInt interface {
  ~int | ~int8 | ~int16 | ~int32 | ~int64
}

type UnsignedInt interface {
  ~uint | ~uint8 | ~uint16 | ~uint32 | ~uint64
}

type BigInt interface {
  ~*big.Int
}

type MaybeBigInt interface {
  BigInt | SignedInteger | UnsignedInteger
}

And have a function which takes MaybeBigInt as a T:

func CheckParseMaybeBigInt[T MaybeBigInt](val T) *big.Int {
   ...
}

Currently I have to do a type switch using (interface{})(val).(type) and check all the possible type values within those constraints (ie. int, int8, etc.), where being able to do

switch n := val.(type) {
case SignedInteger:
  return big.NewInt(int64(n))
case UnsignedInteger
  return new(big.Int).SetUint64(uint64(n))
case BigInt:
  return n
}

would be infinitely cleaner and far easier to code.

I realize this is on hold, but FWIW started migrating a codebase to generics today and accidentally did a similar thing as mentioned in the description when using any() to perform a type cast:

In one concrete example I typed the following:

switch v := (interface{})(item).(type) { …

and was having trouble figuring out why my code was failing. What I had meant to type was item.Value or something along those lines

switch ((any)(v)).(type) seem to work well enough.

This is a valid (hypothetical) Go code:

type Left[T any] struct{ Value T }
type Right[T any] struct{ Value T }

type Either[T any, V any] interface{ Left[T] | Right[V] }

func action[T Either[int, string]](v T) {
	switch ((any)(v)).(type) {
	case Left[int]:
		fmt.Println("Left")
	case Right[string]:
		fmt.Println("Right")
	}
}

func sampleCall(v Left[int]) { action(v) }

And it seems type assertion on v would not be (readily) possible. If I understand correctly (let's say partially), Left[T] and Right[T] are types. But Either[T, V] is not a type. It is a type constraint (so, it is not possible to define a function like func fn(v Either[int, string]) {}). Not sure about the underlying implementation details, but providing type switches over v means providing type switches over type constraints.

func typeSwitchLab1(val interface{}) {
	switch val.(type) {
	case int:
		fmt.Println("int")
	case string:
		fmt.Println("string")

		// case Either[int, string]: <- this is not valid
	}
}

func typeSwitchLab2[T Either[int, string]](val T) {
	/*
		switch val.(type) { <- this is not valid
		case Left[int]:
			fmt.Println("Left")
		case Right[string]:
			fmt.Println("Right")
		}
	*/
}

If type constraints participate in type switches, then type constraints will also be types (in that case, should all type parameters be already known/resolved?).

I vouch neither for nor against this feature. I am just curious about the amount of its real-world usage and how it might change the current implementation (and how the added semantic complexity would look like).

@dc0d I don't really understand your question. As you've shown, you can currently do a type switch on a generic value (https://go.dev/play/p/arj825wElvB) - your typeSwitchLab2 would work if it did the type switch on any(val). Allowing that conversion to be omitted is the essence of this proposal AIUI.

In your typeSwitchLab1 example, it would work fine to switch on Left[int] or Right[string] as opposed to Either[int, string] - both of those being concrete types allowed by the Either constraint.

See this issue for a proposal that would allow putting a constraint in a type switch case: #45380.

If that were implemented, you could do:

func typeSwitchLab3[T any](val T) {
	switch type T {
	case Either[int, string]:
		fmt.Println("Either")
	default:
		fmt.Println("Other")
	}
}

@rogpeppe As stated at the end, it was not a question. It was an "opinion" based on the speculated required changes needed for this feature (including re-scoping type constraints with multiple overloaded meaning/semantics - including type switching over type constraints and not just types). The amount of complexity and cognitive load added by this feature could surpass the value it provides.