You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since all types in the case statement are int, I would expect t to be either an int or int64 inside of the case statement.
What did you see instead?
When given multiple items on a case statement, t is interface{} instead of the concrete type.
More
I think I understand why this behavior exists. For example, given:
switcht:=v.(type) {
caseint, string:
}
t isn't specific enough.
I would expect either one of the following:
This is a compile-time error. Attempting to switch on a type assertion where a case statement has more than one value and the concrete type is used inside the case does not compile.
If all the types are of the same type family, allow it.
Without this, you're left with some rather unnecessarily and possibly error-prone Go code like:
This is intentional and written in the language spec.
The TypeSwitchGuard may include a short variable declaration. When that form is used, the variable is declared at the end of the TypeSwitchCase in the implicit block of each clause. In clauses with a case listing exactly one type, the variable has that type; otherwise, the variable has the type of the expression in the TypeSwitchGuard.
Go doesn't really have a way of unioning two types, so that's what we have to do.
Closing. Any change here would have to go through the proposal process.
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
https://play.golang.org/p/RSGBp79HzqT
What did you expect to see?
Since all types in the case statement are int, I would expect
t
to be either anint
orint64
inside of the case statement.What did you see instead?
When given multiple items on a
case
statement,t
isinterface{}
instead of the concrete type.More
I think I understand why this behavior exists. For example, given:
t
isn't specific enough.I would expect either one of the following:
This is a compile-time error. Attempting to switch on a type assertion where a case statement has more than one value and the concrete type is used inside the case does not compile.
If all the types are of the same type family, allow it.
Without this, you're left with some rather unnecessarily and possibly error-prone Go code like:
versus the much shorter and possibly less error-prone:
The text was updated successfully, but these errors were encountered: