In the TypeScript tuple type `[string, number?, ...boolean[]]`, what do the `?` and the `...` mean, and what is that tuple's `length` type?

## Beyond fixed-length tuples A plain tuple type such as `[string, number]` describes an exact shape. Two modifiers relax that in controlled ways: the optional marker `?` and the rest element `...`. Both are compile-time only — the emitted JavaScript is an ordinary array either way. ## Optional elements An element written with `?` may be absent: ```typescript type Pair = [string, number?]; const a: Pair = ['a']; // ok — second element omitted const b: Pair = ['a', 1]; // ok ``` Two consequences matter in interviews. First, reading the optional position gives you `number | undefined`, so under `strictNullChecks` you must handle the missing case before using it: ```typescript const p: [string, number?] = ['a']; const n = p[1]; // number | undefined // const m = n + 1; // Error: object is possibly 'undefined' ``` Second, the length is no longer a single literal. `Pair['length']` is `1 | 2` — a union of the sizes the type permits. That union is genuinely useful: a `switch (t.length)` over it narrows which positions exist. Ordering is enforced. A **required element may not follow an optional one**, exactly as with function parameters: `[string?, number]` is rejected, because there would be no way to write a value that omits the first element while supplying the second. ## Rest elements A rest element absorbs an open-ended run of positions: ```typescript type Row = [string, ...number[]]; const r1: Row = ['id']; const r2: Row = ['id', 1, 2, 3]; ``` The rules the compiler enforces: at most **one** rest element per tuple, and an optional element may not follow it. What surprises people is that the rest element does **not** have to be last. A tuple may put fixed elements after the rest run: ```typescript type Trailing = [...string[], number]; // any number of strings, then one number const t: Trailing = ['a', 'b', 7]; ``` This is what makes tuple types able to describe argument lists like "a callback always comes last". ## The length type, precisely The rule is simple once you see it as "can the compiler enumerate the possible sizes?": - `[string, number]` → `length` is `2` - `[string, number?]` → `length` is `1 | 2` - `[string, number?, ...boolean[]]` → `length` is `number` Once a rest element is present the set of sizes is infinite, so the compiler falls back to `number` and you lose out-of-range index errors along the rest run. That is a real tradeoff: a rest element buys flexibility and spends the strongest guarantee a tuple has. ## Reading positions inside the rest run Within the fixed prefix, index reads are precise: for `[string, number?, ...boolean[]]`, `t[0]` is `string`. Beyond the fixed part, an index read is typed by the rest element's type — reads land in `boolean` territory rather than erroring, because the compiler cannot know where the array actually ends. This is the same open-endedness that plain arrays have, confined to the tail of the tuple. ## Where this shows up in real code The common uses are argument lists and heterogeneous records: ```typescript // A logging call: a message, an optional severity, then any number of tags. type LogArgs = [message: string, level?: 'warn' | 'error', ...tags: string[]]; declare function log(...args: LogArgs): void; log('started'); log('slow query', 'warn'); log('failed', 'error', 'db', 'retry'); ``` Because the tuple sits in the rest-parameter position, the optional element behaves like an optional parameter and the rest element like a rest parameter — one type expresses the whole signature. ## Common mistakes The first is expecting `t.length` on a rest-bearing tuple to still be a literal and building a `switch` on it. The second is assuming `?` means "may be `undefined`" rather than "may be absent": `['a', undefined]` is accepted for `[string, number?]` because the optional element's type includes `undefined`, but the two situations are not the same for code that checks `t.length`. The third is trying to write two rest elements, or an optional element after the rest — both are compile errors, and the fix is almost always to model the value as an object instead, because a shape that needs those is no longer positional in any readable sense.