3 min read
A long type switch example
We’ve been looking at type switches since last week. Today the spec shows us a large example, comparing type switches to the equivalent expressed without them. Type switches … Given an expression x of type interface{}, the following type switch: switch i := x.(type) { case nil: printString("x is nil") // type of i is type of x (interface{}) case int: printInt(i) // type of i is int case float64: printFloat64(i) // type of i is float64 case func(int) float64: printFunction(i) // type of i is func(int) float64 case bool, string: printString("type is bool or string") // type of i is type of x (interface{}) default: printString("don't know the type") // type of i is type of x (interface{}) } could be rewritten:
1 min read
nils in type switches
Type switches … Instead of a type, a case may use the predeclared identifier nil; that case is selected when the expression in the TypeSwitchGuard is a nil interface value. There may be at most one nil case. Straight forward, right? Here’s an example: switch x.(type) { case int: case string: case nil: } But now here’s a question: If we assign x.(type) to a temporary variable the TypeSwitchGuard, what is its type in the nil case?
2 min read
Temporary variables in type switches
Type switches … TypeSwitchStmt = "switch" [ SimpleStmt ";" ] TypeSwitchGuard "{" { TypeCaseClause } "}" . TypeSwitchGuard = [ identifier ":=" ] PrimaryExpr "." "(" "type" ")" . TypeCaseClause = TypeSwitchCase ":" StatementList . TypeSwitchCase = "case" TypeList | "default" . 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.
2 min read
Uniqueness of type switch cases
Finally, the last important bit from this paragraph: Type switches … Cases then match actual types T against the dynamic type of the expression x. As with type assertions, x must be of interface type, but not a type parameter, and each non-interface type T listed in a case must implement the type of x. The types listed in the cases of a type switch must all be different. Today we’re examining this part:
2 min read
Type switching to non-implementing types
More live coding today! Join me in just a few hours for some more Go TDD work on my kivik library. Today we’re continuing to disect this paragraph: Type switches … Cases then match actual types T against the dynamic type of the expression x. As with type assertions, x must be of interface type, but not a type parameter, and each non-interface type T listed in a case must implement the type of x.
2 min read
Type switching on a non-interface value. Sorta.
Type switches … Cases then match actual types T against the dynamic type of the expression x. As with type assertions, x must be of interface type, but not a type parameter, and each non-interface type T listed in a case must implement the type of x. The types listed in the cases of a type switch must all be different. TypeSwitchStmt = "switch" [ SimpleStmt ";" ] TypeSwitchGuard "{" { TypeCaseClause } "}" .
1 min read
Type switches
Back in December we looked at type assertions, which allow us to assert whether an interface type is of a specific underlying type. In that conversation, I promised we’d get to the more flexible type switches. And now, at long last, we have arrived! Type switches A type switch compares types rather than values. It is otherwise similar to an expression switch. It is marked by a special switch expression that has the form of a type assertion using the keyword type rather than an actual type:
Subscribe to Boldly Go: Daily
Every day I'll send you advice to improve your understanding of Go. Don't miss out! I will respect your inbox, and honor my privacy policy.
Unsure? Browse the archive.
2 min read
Expression switches conclusion
We have just two more points (and some examples) before finishing the topic of expression switches, so let’s get to it. Expression switches … The switch expression may be preceded by a simple statement, which executes before the expression is evaluated. You may recall the discussion of “simple statements” from before. They can exist in an if expression as well. switch x := foo(); x { In this example, x := foo() is the simple statement.
2 min read
Fallthrough statements
Expression switches … In a case or default clause, the last non-empty statement may be a (possibly labeled) “fallthrough” statement to indicate that control should flow from the end of this clause to the first statement of the next clause. Otherwise control flows to the end of the “switch” statement. A “fallthrough” statement may appear as the last statement of all but the last clause of an expression switch.
2 min read
Case expressions
I’m back live streaming again! Join me in just over an hour! Bring your questions, too! Expression switches … If a case expression is untyped, it is first implicitly converted to the type of the switch expression. For each (possibly converted) case expression x and the value t of the switch expression, x == t must be a valid comparison. In other words, the switch expression is treated as if it were used to declare and initialize a temporary variable t without explicit type; it is that value of t against which each case expression x is tested for equality.
2 min read
Switch expressions
Expression switches … If the switch expression evaluates to an untyped constant, it is first implicitly converted to its default type. The predeclared untyped value nil cannot be used as a switch expression. The switch expression type must be comparable. In this paragraph, “switch expression” refers to the expression that optionally comes after the switch keyword, as in: switch len(x) { So first off, if it’s a untyped constant, it’s first converted to its default type.