Switch Exhaustiveness with never

## What a union type lets you touch A union type `A | B` says the value is one of the members, but not which one. The compiler must keep every property access safe for *all* possibilities, so on the un-narrowed value you can only reach members that are present on every arm with compatible types. For `Shape`, that is `kind` alone. Writing `shape.radius` before the switch produces an error along the lines of *Property 'radius' does not exist on type 'Shape'* — because it does not exist on the square arm. This is not the compiler being pedantic. At runtime the value really might be the square, and `undefined.radius`-style bugs are exactly what the union is protecting you from. ## What makes the union *discriminated* The union is discriminated because each member declares the same property name with a **literal** type — `'circle'` and `'square'` — rather than `string`. A literal type has exactly one inhabitant, so a successful comparison against that literal is enough information to identify the member. ```ts type Shape = | { kind: 'circle'; radius: number } | { kind: 'square'; side: number }; ``` ## How the switch narrows TypeScript runs control-flow analysis over the function body. When it sees `switch (shape.kind)`, it recognises that the switched expression is a discriminant property read directly off a union-typed value. For each `case` clause it then filters the union: any member whose tag type cannot equal that case's literal is dropped from the type of `shape` inside that clause. ```ts function describe(shape: Shape): void { switch (shape.kind) { case 'circle': // shape: { kind: 'circle'; radius: number } console.log('circle r =', shape.radius); break; case 'square': // shape: { kind: 'square'; side: number } console.log('square s =', shape.side); break; } } ``` The narrowing applies to the variable itself, not only to the property you compared — that is the whole point of a discriminant. Nothing is copied or converted; the compiler simply reasons about a smaller type in that region of code. ## Fallthrough gives you the union of the arms If two case labels share a body, the body sees the union of the matched members, so once again only the common properties are accessible: ```ts function label(shape: Shape): string { switch (shape.kind) { case 'circle': case 'square': return shape.kind; // shape is still Shape here; shape.radius would error } } ``` The same is true after the `break` — narrowing is scoped to the branch, not to the rest of the function. ## An if/else chain does the same thing `if (shape.kind === 'circle') { ... }` narrows identically; the comparison operator and the switch clause feed the same analysis. A switch is just the compact form when you are comparing one discriminant against many literals, and it makes the tail branch a natural place to reason about what is left over. ## None of this exists at runtime Types are erased. The compiler emits a plain `switch` on a string value; there is no injected check, no reflection, no per-case validation. The narrowing is a *statement about your code*, and it is only as true as the claim that the value really matches the declared type. If the value came from an unvalidated cast, the type says circle while the data says something else, and the emitted code will happily read `undefined`. ## The mistakes that show up in interviews A weak answer reaches for a cast — `(shape as Circle).radius` — which silences the checker without adding any safety, or sprinkles optional chaining `shape.radius?` to make the error go away. Neither is needed: the switch already proved which member you hold, and taking the narrowing is both safer and shorter than defeating it.