In TypeScript, what do `string | never` and `string & never` each reduce to, and why does `{ a: string } & { a: number }` give the `a` property the type `never`?

## Types as sets The cleanest way to predict what TypeScript does with `never` is to read each type as a set of values, `|` as set union and `&` as set intersection. `never` is the empty set. From there the rules are arithmetic: - **Union**: `T | never` = `T`. Adding nothing to a set changes nothing, so `never` is the *identity* element for `|` and simply disappears. - **Intersection**: `T & never` = `never`. Intersecting with nothing leaves nothing, so `never` is the *absorbing* element for `&`. ```ts type A = string | never; // string type B = string & never; // never ``` Because the reduction happens eagerly, you rarely *see* a `never` in a union in editor tooltips — it has already been removed by the time the type is displayed. ## Intersections that collapse on their own You do not have to write `never` to get one. An intersection of two types with no common members reduces to `never` by itself: ```ts type Impossible = string & number; // never — no value is both ``` This is the same computation. `string` and `number` are disjoint sets, so their intersection is empty, and the empty type is spelled `never`. ## Property-wise intersection of object types Object types intersect **per property**. `{ a: string } & { a: number }` keeps the key `a` and gives it the intersection of the two declared types: ```ts type Both = { a: string } & { a: number }; declare const both: Both; const value: never = both.a; // a is string & number, i.e. never ``` Note what did *not* happen: the whole object type did not become `never`. `Both` is still an object type with one property — you can declare a variable of it, and you can read `both.a`. What you cannot do is *construct* one, because you would need a value for `a` and none exists. This is a classic trap when merging configuration or prop types from two sources: the type compiles, code that reads it compiles, and only the code that has to produce a value fails, often far away and with a confusing message. ```ts // const oops: Both = { a: "x" }; // Error: 'string' is not assignable to 'never' ``` If you actually wanted "either shape", the operator was `|`, not `&`. ## Why the union rule matters: filtering The disappearing-from-unions behaviour is the mechanism behind type-level filtering. Conditional types distribute over a union member by member, and any member that maps to `never` is dropped from the result, because `never` contributes nothing to a union. That is how the built-in `Exclude` produces a smaller union, and it is why a filter that rejects *every* member yields `never` rather than an empty union — TypeScript has no separate spelling for "union of nothing"; `never` **is** that spelling. The practical consequence: a generic type that quietly computes `never` gives you a type nothing can satisfy. Downstream, callers get errors like "not assignable to type 'never'" at a call site far from the definition. When debugging a generic, hover the intermediate aliases and look for the point where a type became `never`. ## Related shapes that surprise people - `never[]` is a perfectly real array type — the array itself exists and can be empty; it just has no valid element, so you can never `push` into it. It commonly appears when an empty array literal has nothing to infer from. - `keyof` of an object type with no keys is `never`, since there are no key names to name. - `Promise<never>` is a promise that can never fulfil with a value, which is the honest type for a promise that only ever rejects. - A function parameter typed `never` can never be called successfully — nothing is assignable to it. That property is what exhaustiveness helpers exploit. ## Rules of thumb 1. Read `|` and `&` as set operations and `never` as the empty set; every reduction follows. 2. `never` in a union is invisible; `never` in an intersection is fatal to that position. 3. An object intersection collapses **per property**, not as a whole — the type stays constructible-looking but is not constructible. 4. When a generic or utility type behaves as if it accepts nothing, check each intermediate step for a silent collapse to `never`.