In JavaScript, what does spreading an array into a call such as `Math.max(...numbers)` actually do, and why can it fail when the array is very large?

## What spread at a call site means Inside a call's argument list, `...expr` expands the value into individual arguments: ```js const nums = [3, 1, 4]; Math.max(...nums); // 4 — identical to Math.max(3, 1, 4) ``` The array is never seen by the callee. `Math.max` receives three separate numeric arguments. That is the whole point: `Math.max([3, 1, 4])` returns `NaN`, because a single array argument is coerced to a number and fails. Spread can be combined freely with ordinary arguments and used more than once: ```js fn(1, ...a, 2, ...b); ``` Evaluation is left to right, so each spread is iterated in place, in order. ## It runs the iteration protocol Spread does not check for an array. It looks up `Symbol.iterator` on the value and drains the iterator. So everything iterable works: ```js Math.max(...new Set([3, 1, 4])); // 4 fn(...'abc'); // three string arguments fn(...someMap); // each entry as a [key, value] pair ``` And anything non-iterable fails loudly: ```js fn(...{ a: 1 }); // TypeError: Found non-callable @@iterator fn(...null); // TypeError ``` That is a meaningful distinction from the older `Function.prototype.apply` route, which accepted any array-like object; spread demands a real iterable, and array-likes such as a DOM-style collection must go through `Array.from` first if they lack `Symbol.iterator`. One consequence of iterating: spreading a generator consumes it, and spreading an infinite sequence never returns. ## Why very large arrays blow up Every spread element becomes an actual argument in the call. Arguments are placed on the engine's stack, and the stack is finite, so there is a ceiling on how many arguments one call can take: ```js const big = new Array(500_000).fill(1); Math.max(...big); // RangeError: Maximum call stack size exceeded (V8) ``` The threshold is engine- and build-specific — commonly around a hundred thousand or so in V8, and it moves with stack depth and configuration — so treating any particular number as safe is a mistake. The failure mode is nasty in production: the code works on every test fixture and every small tenant, then throws on the one dataset that crosses the line. It also fails *late*, after the array has already been assembled. ## What to do instead Don't tune the limit — remove the dependency on it. Fold over the array rather than turning it into arguments: ```js const max = big.reduce((m, n) => (n > m ? n : m), -Infinity); ``` A plain loop is equally good and often faster. If the API genuinely needs a variadic call, process the data in fixed-size chunks and combine the partial results: ```js let best = -Infinity; for (let i = 0; i < big.length; i += 10_000) { best = Math.max(best, ...big.slice(i, i + 10_000)); } ``` The same reasoning applies to any variadic API you feed from user-sized data — pushing many elements into an array with `arr.push(...items)`, for example, has exactly the same ceiling, and `for (const item of items) arr.push(item)` does not. ## Spread versus rest The same `...` token means the opposite thing depending on where it appears. In a *parameter list* it is a rest parameter and **collects** arguments into an array. At a *call site* it is spread and **expands** an iterable into arguments. `function f(...a) {}` and `f(...arr)` are mirror images, and the pair round-trips: `f(...[1, 2, 3])` inside `function f(...a)` gives `a` back as `[1, 2, 3]`. ## What to say Start with "it iterates and passes each element as a separate argument", note that it works on any iterable and throws on non-iterables, then give the scaling answer: the element count becomes the argument count, engines cap that, and the fix is a fold or chunking rather than a bigger stack. The last part is what makes this a senior answer instead of a syntax recital.