In TypeScript, given `type A = { id: number; name: string }` and `type B = { id: number; age: number }`, what is `keyof (A | B)`, and what rule produces that answer?

## The result ```ts type A = { id: number; name: string }; type B = { id: number; age: number }; type K = keyof (A | B); // "id" ``` Not `"id" | "name" | "age"`. `keyof` applied to a union yields only the keys that **every** member declares. ## The rule behind it `keyof` distributes across the union and the per-member results are combined with an intersection: ``` keyof (A | B) === keyof A & keyof B ``` Substituting: `keyof A` is `"id" | "name"`, `keyof B` is `"id" | "age"`. The intersection of two unions of literal types keeps only the literals that appear in both, so `("id" | "name") & ("id" | "age")` reduces to `"id"`. Why an intersection rather than a union? Because a union type is a statement of uncertainty. A value typed `A | B` is *one of* those shapes, and the checker does not know which. The only property accesses it can guarantee are those that succeed no matter which member you actually hold. `name` exists on `A` but not on `B`, so it is not a key of the union. Returning `"id" | "name" | "age"` would license `value[k]` for a key that may not exist — unsound. This lines up with what you already know about reading properties from a union value: without narrowing, you can only touch shared members. `keyof` is the type-level statement of that same fact. ## The mirror case: intersections The two operators swap: ```ts type J = keyof (A & B); // "id" | "name" | "age" ``` An intersection value satisfies *both* shapes at once, so every key of either is available, and `keyof (A & B)` is `keyof A | keyof B`. The pairing is worth memorising as one fact rather than two: **`keyof` of a union is the intersection of the keys; `keyof` of an intersection is the union of the keys.** ## The `never` case When union members share no keys, the intersection is empty: ```ts type X = { a: string }; type Y = { b: number }; type Empty = keyof (X | Y); // never ``` `never` is the empty set of possibilities, and it usually shows up as a downstream mystery rather than an error at this line. A helper that does something per key will produce a type with no members; a function whose parameter is typed `keyof (X | Y)` becomes uncallable, because no value inhabits `never`. If a generic helper is behaving as though a type had no properties, check whether the argument was a union of dissimilar shapes. ## Where it bites The usual encounter is a helper written against `keyof T` that works perfectly on a single object type and collapses when someone instantiates it with a union — a discriminated union of message shapes, say, or a state type with several variants. The helper is not wrong; `keyof` is telling the truth about what a union guarantees. Discriminated unions are the interesting sub-case: the discriminant property is by construction present on every member, so it survives the intersection while all the variant-specific fields disappear. If you genuinely want the union of every member's keys, that is a different computation — you have to apply `keyof` to each member separately and union the results, rather than applying it to the union as a whole. Reach for that deliberately, and be aware that the resulting key set is *not* safe for reading properties off a union-typed value; it describes what some member might have, not what any given value does have. ## Erasure, as always None of this is observable at runtime. `keyof (A | B)` is a compile-time computation over declared shapes; the emitted JavaScript contains no trace of it, and it says nothing about which properties a particular object carries when the program runs. It constrains what the checker will let you write, and that is the whole of its effect.