proposal: spec: Values assigned to multi-case branches in type switches should have generics-style

[jmillikin]

Go Programming Experience

Experienced

Other Languages Experience

C, C++, Python, Rust, Haskell

Related Idea

• Has this idea, or one like it, been proposed before?
• Does this affect error handling?
• Is this about generics?
• Is this change backward compatible? Breaking the Go 1 compatibility guarantee is a large cost and requires a large benefit

Has this idea, or one like it, been proposed before?

#65031 seems similar, although the details differ.

#57644 is possibly related, but I can't tell from its description what effect (if any) it would have on type switches.

Does this affect error handling?

No

Is this about generics?

Yes -- this proposal is to make multi-case type switches match the semantics of generic functions with a set of permitted types.

Proposal

In Go 1.23, a value assigned as the match result in a multi-case type switch retains the original type being inspected. This prevents it from being passed to a function with a type parameter constraint that's only satisfied by the narrowed type.

func fmtUint[T uint8 | uint16 | uint32 | uint64](value T) string {
	return strconv.FormatUint(uint64(value), 10)
}

// error: any does not satisfy uint8 | uint16 | uint32 | uint64
func fmtValue(value any) string {
	switch v := value.(type) {
	case uint8, uint16, uint32, uint64:
		// `v` is known to be of the above listed concrete types,
		// but its type remains `interface{}`, so it can't be used as `T`.
		return fmtUint(v)
	}
	return fmt.Sprintf("%v", value)
}

// semantically equivalent, and valid in Go 1.23, but overly verbose
func fmtValue(value any) string {
	switch v := value.(type) {
	case uint8:
		return fmtUint(v)
	case uint16:
		return fmtUint(v)
	case uint32:
		return fmtUint(v)
	case uint64:
		return fmtUint(v)
	}
	return fmt.Sprintf("%v", value)
}

I propose to change the semantics of multi-case type switches so that the type of the matched variable becomes the intersection of the matched types, plus the original type:

interface {
	// To preserve existing behavior, `v` can be treated as its original type.
	any

	// `v` can also satisfy type parameter conditions that permit all of the types
	// in its case match.
	( uint8 | uint16 | uint32 | uint64 )
}

The matched case must have types that are a subset of the generic type:

// OK: `v` might be a `uint8` or `uint16`, but both of those are acceptable to `fmtUint`
func fmtValue(value any) string {
	switch v := value.(type) {
	case uint8, uint16:
		return fmtUint(v)
	}
	return fmt.Sprintf("%v", value)
}

// Error: `v` might be `uintptr`, so the set of possible types is a superset of those
// accepted by`fmtUint`.
func fmtValue(value any) string {
	switch v := value.(type) {
	case uint8, uint16, uint32, uint64, uintptr:
		return fmtUint(v)
	}
	return fmt.Sprintf("%v", value)
}

The type of v should also work with the semantics of a generic type parameter for regular code within the case, for example performing conversions that are valid for all matchable types:

// OK: all of the matched types can be cast to uint64.
func fmtValueHex(value any) string {
	switch v := value.(type) {
	case uint8, uint16, uint32, uint64:
		return strconv.FormatUint(uint64(v), 16)
	}
	return fmt.Sprintf("%v", value)
}

Language Spec Changes

No response

Informal Change

No response

Is this change backward compatible?

I think so? Given existing and proposed behavior, I believe that any existing code would continue to compile and run without changes.

Orthogonality: How does this change interact or overlap with existing features?

No response

Would this change make Go easier or harder to learn, and why?

No response

Cost Description

No response

Changes to Go ToolChain

No response

Performance Costs

No response

Prototype

No response

[gabyhelp]

Related Issues and Documentation

• proposal: Go 2: type switch case statements with multiple interface types should produce an intersection of methods #65031 (closed)
• Type switch with multiple cases loses concrete type #41740 (closed)
• proposal: spec: generics: type switch on parametric types #45380
• proposal: spec: support user-defined variance (allow type parameters as type bounds) #67513
• spec: type switch ranges #5743 (closed)
• type switch fails when multiple cases are put together #64421 (closed)
• proposal: spec: generics: make type parameters discoverable from interfaces #50681 (closed)
• proposal: Go 2: "Matching switch", a new mode of switch statement for concisely matching interface values #67372 (closed)
• proposal: spec: allow type conversion from generic type to same underlying type #61164
• Type switch doesn't support multiple-cases? #36616 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[zigo101]

This is just a specific case of supporting values of non-basic interfaces.

interface {
	// To preserve existing behavior, `v` can be treated as its original type.
	any

	// `v` can also satisfy type parameter conditions that permit all of the types
	// in its case match.
	( uint8 | uint16 | uint32 | uint64 )
}

is equivalent to

interface { uint8 | uint16 | uint32 | uint64 }

The proposal is equivalent to to support:

var v interface { uint8 | uint16 | uint32 | uint64 } = 123
var _ = uint64(v)

[ianlancetaylor]

Something like this is a good idea, but it needs to be part of a larger change, such as allowing type constraint interfaces in arbitrary positions. It is also related to type switches over type parameters (#45380).

If we do this, it would probably make more sense, and be more backward compatible, to use a different syntax:

    case uint8 | uint16 | uint32 | uint64 | uintptr:

Putting on hold for now.