In TypeScript, how do you use `infer` inside tuple patterns to extract a tuple type's first element type, its remaining elements, and its last element type?

## Tuples are matchable shapes A tuple type such as `[string, number, boolean]` records both the element types and their positions. That makes it a rich pattern to match against, and `infer` inside a tuple pattern is how you take it apart. The syntax deliberately mirrors JavaScript array destructuring, which is why it reads naturally even to someone seeing it for the first time. ```ts type Head<T extends readonly unknown[]> = T extends readonly [infer H, ...unknown[]] ? H : never; type Tail<T extends readonly unknown[]> = T extends readonly [unknown, ...infer R] ? R : never; type Last<T extends readonly unknown[]> = T extends readonly [...unknown[], infer L] ? L : never; type A = Head<[string, number]>; // string type B = Tail<[string, number]>; // [number] type C = Last<[string, number]>; // number ``` ## The rest position captures a tuple The single most common misunderstanding is what `...infer R` produces. It is a **tuple type**, preserving order and arity — `Tail<[1, 2, 3]>` is `[2, 3]`, not `2 | 3` and not `(2 | 3)[]`. That is what makes these patterns composable: the output of `Tail` is itself a tuple you can feed straight back into another tuple pattern, which is how list-like type helpers are built up. A rest element in a pattern is not restricted to the end. `[...unknown[], infer L]` is a legal pattern with a *leading* rest, and it is the idiomatic way to reach the final element. Getting the order backwards — writing `[infer L, ...unknown[]]` and calling it `Last` — is the classic slip. ## Open arrays do not match tuple patterns ```ts type X = Head<string[]>; // never ``` `string[]` describes an array of unknown length, possibly empty, so it is not assignable to a pattern that demands at least one element. The conditional therefore takes the false branch. This is correct rather than a limitation: the type system genuinely does not know that a `string[]` has a first element, and a helper that pretended otherwise would be unsound. If you want to accept both, write the array case as a separate branch: ```ts type FirstOf<T extends readonly unknown[]> = T extends readonly [infer H, ...unknown[]] ? H : T extends readonly (infer U)[] ? U | undefined : never; ``` The `| undefined` there is deliberate honesty about a possibly-empty array. ## Empty tuples and the false branch `Head<[]>`, `Tail<[]>` and `Last<[]>` all fall to the false branch, because `[]` satisfies none of the three patterns. Returning `never` for those cases is the usual choice, and it gives a visible failure downstream. If a helper needs to keep working on an empty input — for example a tail that should stay a tuple — return `[]` from the false branch instead of `never`. ## Constraining the parameter Writing `T extends readonly unknown[]` on the type parameter itself is worth doing. It gives callers an immediate, readable error when they pass a non-tuple, instead of silently handing them `never` from deep inside the conditional. It also documents intent: this helper is about list-shaped types. The `readonly` in both the constraint and the pattern widens what matches. A mutable `[string, number]` is assignable to `readonly [string, number]`, so the readonly form accepts both; the reverse is not true, so a pattern written without `readonly` silently rejects readonly tuples — a frequent cause of an unexplained `never`. ## It is all erased None of this touches runtime. There is no array being taken apart; the compiler is matching type shapes during checking and emits nothing. A helper called `Tail` produces no code and cannot be called — it exists only where types are written.