Intersection Types

An intersection is a conjunction. Serializable & Comparable describes values that are both, so every operation of both is available on it. This is the mirror image of [[union-types]]: a union has fewer values excluded and therefore fewer operations available; an intersection has more values excluded and therefore more operations available. The set arithmetic and the operation arithmetic always run in opposite directions, and the cardinality argument in [[algebraic-data-types]] is where that stops being a coincidence.

For object types the merge is what you would expect: { a: number } & { b: string } has both properties. For function types it is not a merge at all — ((x: string) => void) & ((x: number) => void) is an overload set, resolved by trying the signatures in order. That asymmetry catches people, and it exists because there is no single signature that means "accepts a string and separately accepts a number"; the only faithful representation is the list.

An intersection is also not the same as inheritance, even though both produce a type with everyone's members. Inheritance declares a nominal edge that survives into the runtime representation and into instanceof; an intersection declares nothing and exists only in the checker. In a nominal language the two are barely comparable — see [[structural-vs-nominal]].

The first honest use is mixins. A mixin is a function that takes a class and returns a class with more members; the return type is naturally the intersection of what went in and what was added, because that is literally what the value is. Trying to express the same thing with inheritance requires a fresh named class per combination, which is combinatorial; the intersection is compositional and costs one type expression.

The second is refining a type you do not control. A library hands you Request; your middleware attaches a user. The type of the object after the middleware is Request & { user: User } — no new declaration, no fork of the library's types, and every existing function that accepts a Request still accepts it. This is the standard shape of typed middleware and it is the reason intersections exist in a structural system at all.

The third is capability constraints on a type parameter. function save<T extends Serializable & HasId>(x: T) says the argument must satisfy two independent requirements which no single interface in the codebase happens to combine. Declaring a SerializableHasId interface would work too, and would then need every implementor updated — which is exactly the versioning cost that makes the structural, anonymous version attractive.

What all three have in common: the intersection is describing a value that genuinely exists and genuinely satisfies both. When you find yourself intersecting types to make an error go away rather than to describe a value, the type is about to become uninhabited.

Write type T = string & number and nothing complains. There is no value that is simultaneously a string and a number, so the type has no inhabitants — and a type with no inhabitants is a perfectly ordinary thing for a type system to have. It is called never in TypeScript, ! in Rust, Nothing in Scala, Void in Haskell, and it is genuinely useful: it is the return type of a function that does not return, and it is what makes the exhaustiveness trick in [[exhaustiveness-checking]] work.

The reason it is not reported at the declaration is that the checker cannot generally decide inhabitation. For primitives it can and does — TypeScript reduces an intersection of provably disjoint primitives to never eagerly. For object types it does not: { a: string } & { a: number } is not reduced to never, it becomes an object type whose a has type string & number, which is never. The object type still has a name, still has a property, and still cannot be constructed. The error, when it comes, comes at the construction site and says something about a rather than about the type as a whole.

This is where intersections turn into a debugging problem. The type expression that is impossible is often several aliases away from the assignment that fails, and the diagnostic points at the assignment. The habit that fixes it is to ask, whenever an intersection surprises you, whether any value could have that type — and to check by trying to write one.

The pathological version is intersecting types with the same method at incompatible signatures. You get an overload set that no implementation can satisfy, the type is fine, every call site resolves, and the only thing that fails is the one place someone tries to implement it.

Intersections are cheap to write and expensive to check. Deciding whether X is assignable to A & B means deciding it against every member; deciding whether A & B is assignable to X means finding *some* combination of members that covers X, which is a search. Combine that with generics and conditional types and the checker is doing real work on every use — this is a well-known source of slow builds in large TypeScript codebases, and the fix is almost always to name the resulting type once rather than re-deriving the intersection at every site.

The diagnostic cost is worse than the time cost. An error against an intersection has to explain which member failed and why, and the natural rendering of that is to print all the members. A four-member intersection of generic object types produces an error message measured in screenfuls, and the useful line is somewhere in the middle. This is the diagnostic-quality problem from [[diagnostic-quality]] in its purest form: the checker knows exactly what is wrong and cannot say it briefly.