In a Go type switch `switch v := x.(type)`, what type does v have in each case?

## The form ```go switch v := x.(type) { case nil: // x is a nil interface value case int: // v is an int case string, []byte: // v still has x's interface type default: // v still has x's interface type } ``` The guard `v := x.(type)` is legal **only** in the head of a switch — it is not an expression you can write anywhere else. `x` must be of interface type, exactly as for a normal assertion. ## What v is bound to This is the part interviewers actually probe. The specification says: in a clause listing **exactly one type**, the variable has that type; **otherwise** it has the type of the guard's expression. So: - `case int:` — `v` is an `int`. You can do arithmetic on it with no further assertion. - `case error:` — the single type is an interface, so `v` is an `error` and you may call `v.Error()`. - `case string, []byte:` — two types, so `v` is still whatever `x` was declared as (`any`, `io.Reader`, …). Calling `len(v)` there does not compile even though both listed types support it; there is no union type in Go. - `default:` — same, `v` keeps the interface type. A useful consequence: in the multi-type and default clauses, `%T` on `v` still prints the dynamic type, which is why `fmt.Sprintf("unhandled: %T", v)` is the standard default-clause line. The binding is per-clause: each clause gets its own `v`, which is why the compiler can give it a different type in each one. You may omit the binding entirely — `switch x.(type) { case int: ... }` — when you only care which branch runs. ## Order matters when cases name interfaces Cases are evaluated top to bottom and the first match wins. With concrete types that is invisible, because a value has exactly one dynamic type and at most one case can name it (naming a type twice is a compile-time duplicate-case error). With **interface** cases it is decisive: a `*os.PathError` matches both `case error:` and `case *os.PathError:`, and whichever appears first is the one that runs. Put the narrow, specific cases above the broad interface cases, or the broad one will swallow everything. This is different from a language with runtime overload resolution: Go does not look for the most specific match, it takes the first textual one. ## case nil `case nil:` matches when the interface value itself is nil — no dynamic type at all. It is the only way to distinguish "nothing was passed" from "a value was passed" inside the switch, and without it a nil interface falls through to `default`. Note that this is a test on the interface value itself, not on whether the concrete value inside it happens to be a nil pointer or a nil map. ## Why it exists Without a type switch you would write a ladder: ```go if i, ok := x.(int); ok { ... } else if s, ok := x.(string); ok { ... } ``` The switch is shorter, evaluates the guard expression once, keeps every branch's variable correctly typed, and makes the exhaustiveness of your handling visible in one screen. It is what the standard library uses when it must dispatch on a decoded, unknown-shape value. ## Where a type switch is the wrong tool If every case does the same thing through the same method, you wanted an interface, not a switch: define the method and let dispatch do the work. If the switch enumerates the concrete implementations of your own interface, it will need editing every time a new one appears, which is exactly the coupling interfaces exist to remove. A type switch earns its place when the values genuinely come from outside your type system — decoded JSON, a plugin registry, a value of type `any` handed to a formatting routine — or when you must handle a fixed, closed set of types that you own together. One last practical note: keep a `default` clause that reports the unexpected type rather than silently doing nothing. A type switch with no `default` over data you do not control is a silent-drop bug waiting for the first payload shape you did not anticipate.