In JavaScript destructuring, what does the rest element bind in `const [first, ...rest] = arr` and `const {id, ...others} = obj`, and what restrictions does the syntax place on it?

## Array rest: drains the iterator into a new array ```js const [first, ...rest] = [1, 2, 3]; // first = 1, rest = [2, 3] const [only, ...none] = [1]; // only = 1, none = [] const [, ...tail] = ['a', 'b', 'c']; // tail = ['b', 'c'] ``` Two properties matter. First, the binding is **always an array** — when the source is exhausted you get `[]`, never `undefined`, so `rest.length` and `rest.map(...)` are safe without a guard. Second, it is a **new** array: the source is not consumed or modified, and `rest` can be mutated freely without touching it. Because the values come from the iterator, holes in a sparse source are materialized: ```js const [...all] = [1, , 3]; // [1, undefined, 3] — dense, three real elements ``` The iterator visits every index up to `length` and produces `undefined` where no property exists, so the result has no holes. ## Object rest: the omit idiom ```js const user = { id: 7, name: 'ada', password: 'hunter2' }; const { password, ...safe } = user; // safe = { id: 7, name: 'ada' }; user is unchanged ``` Object rest copies the source's remaining **own enumerable** properties — string and symbol keys — into a fresh plain object. That makes it the idiomatic non-mutating "remove this key" operation, far cleaner than copying and then `delete`-ing. As with object spread, inherited and non-enumerable properties are not included, and getters on the source are invoked so the copy holds their computed values. A subtlety: the omitted key still creates a binding. `const { password, ...safe } = user` declares `password` in scope, which linters configured to reject unused variables will flag — most such rules have an option to ignore names consumed by a rest sibling. To omit a key whose name is computed, extract it under an alias: `const { [key]: _removed, ...others } = obj`. ## The syntactic rules All of these fail at parse time, before anything runs: ```js const [...head, last] = arr; // SyntaxError: rest element must be last const [a, ...rest, ] = arr; // SyntaxError: trailing comma after rest const [...rest = []] = arr; // SyntaxError: rest element may not have a default ``` The "must be last" rule follows from the mechanism: rest consumes everything remaining, so there is nothing left for a later target to match. "No default" follows from the guarantee that rest is always a container — the empty case is already covered by `[]` or `{}`, so a fallback would be meaningless. Only one rest element is allowed per pattern level, though nested patterns can each have their own: `const [{ id, ...restOfFirst }, ...restOfList] = items` is valid. ## Rest is shallow, like every other copy here ```js const src = [{ n: 1 }, { n: 2 }]; const [, ...tail] = src; tail[0] === src[1]; // true tail[0].n = 99; // src[1].n is now 99 ``` The container is new; the elements inside it are the same references. The same holds for object rest — `others.nested` is the source's nested object. Treat a rest binding exactly as you treat a spread copy. ## Rest versus spread — same three dots, opposite direction The token `...` means "gather" on the left of an assignment (in a binding pattern) and "scatter" on the right (in an array literal, object literal, or call argument list): ```js const [head, ...tail] = list; // rest: gathers remaining values const copy = [head, ...tail]; // spread: scatters them back ``` Being able to state that duality crisply — the same syntax, the position decides the meaning — is usually what the interviewer is checking, alongside the always-an-array guarantee and the last-position rule. ## Version notes Array rest in destructuring is part of ES2015. Object rest and object spread arrived later, in ES2018, which is why older code often uses a helper or `Object.assign` for the omit idiom instead.