In TypeScript, what do the built-in utility types `Exclude<T, U>`, `Extract<T, U>` and `NonNullable<T>` produce when you apply them to a union type?

## The mental model: unions are sets A union type like `'draft' | 'live' | 'archived'` behaves like a set of three possibilities. `Exclude`, `Extract` and `NonNullable` are the set operations over that set: difference, intersection, and "remove the two nullish members". They live in TypeScript's standard library (`lib.es5.d.ts`), so they are always available without an import, and like everything in the type layer they exist only during compilation — the emitted JavaScript contains nothing from them. ## Exclude<T, U> — set difference `Exclude<T, U>` keeps the members of `T` that are **not** assignable to `U`: ```ts type Status = 'draft' | 'live' | 'archived'; type Editable = Exclude<Status, 'archived'>; // 'draft' | 'live' type NotFn = Exclude<string | number | (() => void), Function>; // string | number ``` The test is *assignability*, not string equality. `Exclude<string | number | (() => void), Function>` removes the function member because a `() => void` is assignable to `Function`. That also means excluding a supertype removes everything under it. One consequence surprises people: the filter is applied to each **member** of a union, and a non-union type is treated as a one-member union. So `Exclude<string, 'a'>` is `string` — `string` is not assignable to the literal `'a'`, so nothing is removed. It does *not* mean "string minus the letter a"; there is no such type. ## Extract<T, U> — set intersection `Extract<T, U>` is the complement: it keeps exactly the members `Exclude` would have thrown away. ```ts type Primitives = string | number | boolean | null; type Textish = Extract<Primitives, string | number>; // string | number type Nope = Extract<string, 'a'>; // never — string is not assignable to 'a' ``` The last line is the mirror image of the `Exclude<string, 'a'>` case and catches candidates out: direction matters. `Extract<'a' | 'b', string>` is `'a' | 'b'` because each literal *is* assignable to `string`, but `Extract<string, 'a'>` is `never` because the wide `string` is not assignable to the narrow `'a'`. ## NonNullable<T> — drop null and undefined ```ts type MaybeUser = { id: string } | null | undefined; type User = NonNullable<MaybeUser>; // { id: string } ``` This matters only when `strictNullChecks` is on; without it, `null` and `undefined` are already absorbed into every type and there is nothing to strip. In current TypeScript (the 5.x line) the standard library defines it as an intersection, `type NonNullable<T> = T & {}`, because the type `{}` means "any value except `null` and `undefined`". The observable behaviour is the same as removing the nullish members. ## Why the results look the way they do When a member fails the filter it becomes `never`, the empty type. `never` is the identity element of a union: `string | never` reduces to `string`. So filtering three members and rejecting one leaves `'draft' | 'live' | never`, which the checker immediately reduces to `'draft' | 'live'`. If **every** member is rejected you are left with `never` alone, and `never` has no values — the first assignment downstream will fail with a confusing error, which is usually the sign that a filter was too aggressive or a literal was misspelled. ## Where you actually use them - Deriving a narrower state union from a wider one: `type OpenTicket = Exclude<TicketState, 'closed' | 'archived'>`. - Pulling one variant out of a tagged union: `Extract<Action, { type: 'add' }>`. - Cleaning up an optional lookup result so downstream code is not forced to re-check for `null`. - Narrowing a callback parameter type after you have already validated it. ```ts function render(status: Exclude<Status, 'archived'>): string { return status === 'draft' ? 'Draft' : 'Live'; } ``` The compiler now rejects `render('archived')` at the call site, and the `switch` inside needs only two branches. ## The runtime boundary None of these does any filtering at run time. `NonNullable<T>` does not check for `null`; it only tells the checker that you have already ruled it out. If the value can actually be `null` at run time, you still need a real check — the utility type just stops the compiler from complaining, which is exactly the failure mode to avoid.