Given `const point: [number, number] = [1, 2]` in TypeScript, why does `point.push(3)` compile even though the type says the tuple holds exactly two elements, and what annotation prevents it?

## The symptom ```typescript const point: [number, number] = [1, 2]; point.push(3); // compiles console.log(point.length); // prints 3; the checker still types it as 2 ``` The tuple type promised exactly two elements. The compiler accepted a call that broke that promise, and afterwards the type and the value disagree — the type says `length` is `2` while the array holds three items. Anything the checker derives from the length is now wrong. ## Why the compiler allows it TypeScript models a tuple as an array with extra knowledge about its positions. That means a tuple value has the **apparent members of `Array<T>`**, where `T` is the union of the element types. For `[number, number]` the inherited method is effectively `push(...items: number[]): number`. That signature says nothing about length — it cannot, because it is the same declaration every array shares. The fixed length is enforced where the compiler models the shape directly: assigning a differently sized literal fails, an out-of-range literal index fails, destructuring is position-typed. It is not enforced through the mutating methods, which route around the shape entirely. For a mixed tuple this also loosens what the mutators accept, because `T` is the union of all positions: ```typescript const entry: [string, number] = ['a', 1]; entry.push('b'); // accepted — 'b' is in string | number entry.push(2); // also accepted ``` So neither the count nor the ordering survives a `push`. ## Is this a bug? It is a known, accepted piece of **unsoundness**, in the same family as bivariant method parameters and unchecked index access. The design constraint behind it is that TypeScript's types are erased: a tuple must be a plain array at runtime, with no wrapper and no cost. Giving tuples their own mutation-aware method declarations would mean either a separate runtime representation or a much larger set of built-in declarations whose length arithmetic the checker would have to track through every call. The trade the language made is that the mutators stay array-shaped, and you opt into safety with `readonly`. ## The fix: readonly tuples ```typescript const safe: readonly [number, number] = [1, 2]; // safe.push(3); // Error: Property 'push' does not exist on // type 'readonly [number, number]' const sum = safe[0] + safe[1]; // reads are unaffected ``` A `readonly` tuple's apparent members come from `ReadonlyArray`, which declares only the non-mutating methods — `map`, `filter`, `slice`, `concat`, `indexOf` and friends. `push`, `pop`, `shift`, `unshift`, `splice`, `sort`, `reverse` and `fill` are absent, so every route that could change the length or reorder the positions is closed. Element assignment is blocked too: `safe[0] = 9` is an error because the indexed positions are readonly. Assignability runs one way: a mutable tuple is assignable to the matching readonly tuple, but not the reverse. That is what makes `readonly` cheap to adopt at a boundary — a parameter typed `readonly [number, number]` still accepts every existing mutable tuple caller, while promising inside the function body that nothing will be mutated. ## Applying it in practice The rule that pays for itself: **use readonly tuples in signatures**, both for parameters you do not mutate and for values you return and expect callers to treat as fixed. ```typescript function distance(a: readonly [number, number], b: readonly [number, number]): number { return Math.hypot(a[0] - b[0], a[1] - b[1]); } ``` That signature documents the contract and enforces it, and because mutable tuples flow in freely it costs callers nothing. Within a function body where you build a tuple and hand it straight out, the mutable form is fine. ## What readonly does not give you It is still compile-time only. `readonly` emits no `Object.freeze`, so a value that reaches your code through `any`, through a type assertion, or from untyped JavaScript can be mutated by whoever holds a mutable-typed reference to the same array. If you need the guarantee at runtime, freeze the array explicitly — `Object.freeze` is a runtime operation and the type layer will not do it for you. The same caution applies to the original hole: `readonly` prevents *your* code from calling `push` through that reference. If the same array is also reachable via a mutable-typed alias elsewhere, the length can still change under you. Confining who holds the mutable reference is a design decision, not something an annotation settles.