In TypeScript, a function `move(x: number, y: number)` is called as `move(...args)`. Why does that fail to compile when `args` is `number[]`, and what type of `args` makes it work?

## The error and what it is protecting ```typescript function move(x: number, y: number): void { /* ... */ } const args = [1, 2]; // inferred as number[] // move(...args); // Error: A spread argument must either have a tuple type // or be passed to a rest parameter. ``` JavaScript is perfectly happy to run this — spread simply expands whatever elements are there, and missing arguments become `undefined`. TypeScript refuses because it is checking **arity**, and `number[]` tells it nothing about arity. The array may hold zero elements, in which case `x` and `y` are both `undefined` at runtime despite being typed `number`; it may hold five, silently discarding three. Rather than guess, the compiler asks for a type that names the length. ## The fix: a tuple type at the call site ```typescript const fixed: [number, number] = [1, 2]; move(...fixed); // ok ``` Now the checker knows there are exactly two elements and what each one's type is, so it can match element 0 against `x` and element 1 against `y`. The same works for a value that got a tuple type any other way — a function's declared tuple return type, a tuple-typed field, or a variable annotated as above. Optional elements are handled too. Spreading a `[number, number?]` into a function whose second parameter is optional is fine, because both the minimum and maximum sizes are known and both fit the signature. ## The other side: a rest parameter typed with a tuple The error message names a second escape hatch — "or be passed to a rest parameter". A rest parameter accepts any number of arguments, so spreading an open-ended array into it is safe: ```typescript function sum(...values: number[]): number { return values.reduce((a, b) => a + b, 0); } const nums: number[] = [1, 2, 3]; sum(...nums); // ok — the receiver imposes no arity ``` More interesting is typing a rest parameter *with a tuple*, which turns a tuple into a full parameter list: ```typescript type MoveArgs = [x: number, y: number]; function moveT(...args: MoveArgs): void { const [x, y] = args; console.log(x, y); } moveT(1, 2); // called like a normal two-parameter function // moveT(1); // Error: expected 2 arguments, got 1 ``` To callers, `moveT` looks and behaves exactly like `move`. The difference is that its parameter list now exists as a *type* that other code can reference, pass around, and spread. ## Why this pairing matters: forwarding The combination — a tuple flowing into a rest parameter, then spread back out into the target call — is how you write a wrapper that preserves a signature without restating it: ```typescript type Args = [x: number, y: number]; function logged(...args: Args): void { console.log('move', args); move(...args); // legal: args has a tuple type } ``` Inside the wrapper, `args` has the tuple type, so spreading it into `move` satisfies the arity check. Without tuple types the only way to write this is to list the parameters again and keep the two lists in sync by hand. ## The runtime picture None of this survives compilation. `move(...args)` emits as `move(...args)` and JavaScript expands the array at call time. The tuple type is the compiler's evidence for a check it performs before erasing everything; if the value actually has a different length at runtime — because it came from `JSON.parse`, or from an `as [number, number]` assertion — the call still runs, and the mismatch shows up as `undefined` inside the function rather than as an error at the call. ## Common mistakes The first is assuming a two-element array literal is already a tuple. Assigning `const args = [1, 2]` widens to `number[]`; the tuple shape comes from an annotation or an explicit tuple-typed context, not from counting the literal's elements. The second is reaching for `move(...(args as [number, number]))` when the array's real length is not guaranteed — the assertion silences the checker without making the claim true, which is precisely the arity bug the error was trying to prevent. The honest fix is to give the value a tuple type where it is *created*, or to check its length at runtime before asserting.