The infer keyword: pattern-match a type and capture a piece of it

A hole in the pattern

When you need to extract a type that lives inside another type you don’t control — the return of a function, the resolved value of a Promise, the first element of a tuple — you could wrap and unwrap manually. Or you can punch a hole in the pattern and let TypeScript solve for it.

infer is only legal inside the extends clause of a conditional type. It declares a new type variable on the spot and lets TypeScript solve for it by matching structure:

type ElementOf<T> = T extends (infer E)[] ? E : never;

type A = ElementOf<string[]>;       // ^? string
type B = ElementOf<[1, 2, 3]>;      // ^? 1 | 2 | 3   (tuple element type)
type C = ElementOf<number>;         // ^? never       (not an array — false branch)

You wrote the shape (infer E)[] — “an array of something” — and TypeScript unifies it against the input, binding E to that something. E exists only in the true branch. This is the same machinery the standard library uses:

type Unwrap<T> = T extends Promise<infer V> ? V : T;
type R1 = Unwrap<Promise<number>>;  // ^? number
type R2 = Unwrap<string>;           // ^? string  (false branch returns T)

type Params<T> = T extends (...args: infer P) => unknown ? P : never;
type R3 = Params<(a: string, b: number) => void>; // ^? [a: string, b: number]

Tuple head, tail, and multiple infers in one pattern

You can place several infer variables in one pattern and capture distinct pieces simultaneously:

type Head<T extends readonly unknown[]> =
  T extends [infer H, ...unknown[]] ? H : never;
type Tail<T extends readonly unknown[]> =
  T extends [unknown, ...infer Rest] ? Rest : never;

type H = Head<[1, 2, 3]>; // ^? 1
type Te = Tail<[1, 2, 3]>; // ^? [2, 3]

type Last<T extends readonly unknown[]> =
  T extends [...unknown[], infer L] ? L : never;
type L = Last<[1, 2, 3]>; // ^? 3

Variadic tuple positions (...infer Rest) make head/tail/last trivial — and they’re the building block for the recursive type-level lists you’ll write in unit 05.

Constrained infer (TS 4.7): infer R extends ...

Before TS 4.7 you had to capture, then re-test in a nested conditional. Since 4.7 you can constrain the inference inline, which both validates and narrows the captured type:

// Capture a string-literal element and narrow it to string in one step
type FirstString<T> =
  T extends [infer S extends string, ...unknown[]] ? S : never;

type S1 = FirstString<["hello", 1, 2]>; // ^? "hello"
type S2 = FirstString<[1, "x"]>;        // ^? never   (first is not a string)

A practical payoff: infer N extends number lets you carry a numeric literal through without it widening, useful in numeric type arithmetic.

The variance twist: same name, multiple positions

This is the part people get wrong. When one infer name appears in multiple positions, TypeScript collects every candidate and combines them — but how depends on variance. In covariant positions (object property values, array elements, return types) the candidates are unioned:

type Co<T> = T extends { a: infer U; b: infer U } ? U : never;
type X = Co<{ a: string; b: number }>;
// ^? string | number   — covariant positions => UNION

In contravariant positions — function parameters — the candidates are intersected:

type Contra<T> =
  T extends { f: (x: infer U) => void; g: (x: infer U) => void } ? U : never;
type Y = Contra<{ f: (x: string) => void; g: (x: number) => void }>;
// ^? string & number   — contravariant positions => INTERSECTION  (here: never)

The cost side: infer is cheap to write, expensive to chain

A single infer is nearly free. The trap is recursive infer — peeling a tuple one head at a time, or unwrapping nested wrappers — because each recursion is a fresh conditional instantiation. TypeScript caps non-tail recursive instantiation at an instantiation depth of about 50 before it gives up with Type instantiation is excessively deep and possibly infinite; tail-recursive forms get further, to roughly 1000 levels. A tuple infer-walk over a 2000-element array literal will hit that wall, and the symptom isn’t a crash — it’s an any silently substituted at the bottom of the recursion, which then poisons every downstream type that depended on it.

The senior breakpoint: infer is the right tool when the piece you need is genuinely inside a type someone else owns — a library’s ReturnType, an Awaited over an unknown promise. It is the wrong tool when you control the type and could just name the piece. type UserId = User["id"] is an indexed access — instant to resolve, trivially hoverable — versus type UserId = Extract<...infer...> which the reader must mentally execute. And when you find yourself writing a 30-line recursive infer to parse a string or a deeply nested shape, that is the signal that the type system is being asked to do a parser’s job: a small codegen/build step that emits a flat named type compiles in microseconds and gives teammates an artifact they can read, where the recursive infer costs seconds of check time and produces an error message no one can decode.