Labeled Tuple Elements

The plain-language idea

The tuples lesson already covered that a tuple's fixed-length, positional typing is what makes [value, setter]-style destructuring work correctly. What it deliberately left for later: [string, number] tells a reader what type each position holds, but not what it means. Two same-shaped tuples used for completely different things — a [string, number] name/age pair versus a [string, number] min/max range — look identical in a hover tooltip. Labeled tuple elements close that gap:

type NameAge = [name: string, age: number];
type Range = [min: number, max: number];

The labels (name, age, min, max) are pure documentation. They show up in editor autocomplete, in hover tooltips, and in error messages — but they compile to exactly the same runtime array as the unlabeled version, and you still destructure by position, not by label.

See it in a real thing: a range-clamping function

function clamp(value: number, [min, max]: [min: number, max: number]): number {
  return Math.min(Math.max(value, min), max);
}

clamp(15, [0, 10]);   // 10 — destructured by position, same as always

Compare the signature to the unlabeled version, [number, number] — a reader (or an editor's parameter hint popup) has no way to tell which number is the floor and which is the ceiling without opening the function body. [min: number, max: number] answers that question at the call site, in the same place TypeScript already shows you the type.

What people usually miss

Watch out

• The label is not a property name. const r: Range = [0, 10]; r.min is a compile error — labeled tuples are still accessed by numeric index (r[0]) or positional destructuring, never r.min. If you actually want named-property access, you want an object type, not a tuple.
• Labels don't add any runtime check or enforcement. Passing [10, 0] (max before min, despite the labels saying otherwise) compiles without complaint — TypeScript checks that the values are numbers in the right positions, not that they satisfy whatever the label's name implies.
• This pairs naturally with optional and rest elements from the base tuples lesson — [name: string, age?: number] and [first: string, ...rest: number[]] both label-annotate perfectly normally; labeling doesn't require giving up any other tuple feature.

Why this matters in interviews

"Given a function with a [number, number] tuple parameter, how would you make its meaning clear without changing its runtime shape or forcing callers into an object?" is a fair follow-up once someone's already demonstrated they understand tuples — labeled elements are the answer, and knowing they're erased at runtime (unlike renaming to an object type, which would change the call site) shows the deeper understanding.