Now, let’s talk about a feature that exists almost entirely to save your sanity and the sanity of the poor soul who has to read your code six months from now (which is probably you, hungover on a Sunday). I’m talking about labeled tuple elements.

You’ve already met the basic tuple: a fixed-length array with a known type for each position. [string, number] means index 0 is a string, index 1 is a number. Simple, right? But also… profoundly dumb. What does const coordinates = [10, 20]; mean? Is that [x, y]? [latitude, longitude]? [price, quantity]? You and I might guess from context, but the TypeScript compiler has no idea. It just sees a string and a number. This is where labels come in. They add a layer of readability on top of the existing type structure without changing the underlying JavaScript behavior one bit.

Think of it like this: the label is a comment that the type system can actually understand and enforce. You’re giving a name to each position.

// A sad, anonymous tuple. I have no idea what these numbers represent.
let point: [number, number] = [10, 5];

// A glorious, labeled tuple. It's a story. A poem. It has meaning.
let labeledPoint: [x: number, y: number] = [10, 5];

See the difference? The type [x: number, y: number] is functionally identical to [number, number] in every mechanical way. You still access the elements by index (labeledPoint[0]). But now, when you hover over labeledPoint in your IDE, you don’t just see (property) 0: number; you see (property) x: number. It’s a tiny victory for clarity that compounds over a large codebase.

Why You Bother: The Principle of Maximum Obviousness

The primary reason to use labels is to make the impossible-to-remember, arbitrary order of tuple elements self-documenting. This is crucial for tuples that represent more complex data structures. Consider a function that returns a HTTP response:

// Without labels: a mystery wrapped in an enigma.
function getResponse(): [number, string, boolean] {
  return [200, "OK", true];
}
const response = getResponse();
console.log(response[1]); // What am I logging? The status message? The body?

// With labels: a model of clarity.
function getLabeledResponse(): [status: number, message: string, isCacheable: boolean] {
  return [200, "OK", true];
}
const labeledResponse = getLabeledResponse();
console.log(labeledResponse[1]); // Still not ideal, but now I can hover and see it's 'message: string'

The labels make the contract explicit. You’re not just getting a number and a string; you’re getting a status code and a message. It tells a story.

The Crucial, Non-Negotiable Rule

Here’s the part the manual often glosses over, and it’s the most common pitfall: labels do not change how you interact with the value at runtime. They are a type-system-only feature. This is a critical distinction.

You cannot access the element by its label name. It is not a property. The following code will cause a runtime error and a compile-time error:

let data: [id: number, value: string] = [42, "Answer"];
console.log(data.id); // Runtime Error: Property 'id' does not exist on type '[number, string]'.
// Compiler Error: Property 'id' does not exist on type '[number, string]'.

You must still use the index. The label is a fancy hat the type wears; the value itself is still just a plain array. This trips people up constantly. The label is for your eyes and your tools, not for your execution logic.

Where Labels Truly Shine: Function Parameters

This feature was practically made for function arguments. Remember that a function’s parameters are essentially a tuple. Using labeled tuple types in rest parameters is where you unlock its superpower.

// A function that takes a variable number of arguments representing a name and scores.
function logScores(...args: [player: string, ...scores: number[]]) {
  console.log(`Player: ${args[0]}`);
  console.log(`Scores: ${args.slice(1).join(', ')}`);
}

logScores("Alice", 99, 85, 100); // Perfectly clear what's being passed.

This signature is infinitely more readable than ...args: [string, ...number[]]. It immediately tells you the first rest argument is a player’s name, followed by their scores.

The Edge Case of Conflicting Labels

What happens if you try to redefine a tuple type with different labels? TypeScript’s designers, in their infinite wisdom, decided that labels are purely for display and don’t affect type compatibility. The underlying structure (the types and order of the elements) is all that matters.

type FirstTuple = [a: string, b: number];
type SecondTuple = [c: string, d: number];

let first: FirstTuple = ["hello", 42];
let second: SecondTuple = first; // This is perfectly fine.

// Even this madness works, because the structure [string, number] is identical.
type AnonymousTuple = [string, number];
let anonymous: AnonymousTuple = second;

This might seem absurd, but it’s the only logical choice. If labels were part of the type identity, you’d create a nightmare of incompatible types that are structurally identical, breaking most of the benefits of a structural type system. It’s a pragmatic choice, even if it feels a bit silly. The label is a comment, and you don’t enforce that two comments must be the same for two pieces of code to be compatible.

So, use labels. Use them everywhere you use tuples. They cost you nothing, they don’t change your runtime code, and they make your intentions blazingly obvious. It’s one of the easiest high-impact habits you can adopt to write TypeScript that doesn’t make people (including future you) want to flip a table.