What happens if you `splice` elements out of an array from inside its own `forEach` callback, and how does a `for...of` loop over the same array behave differently?

## Both loops read the live array JavaScript arrays give you no concurrent-modification guard. There is no exception, no snapshot, no "the collection changed" error — the loops just keep reading the array as it is at that instant. The two constructs differ in *when* they consult `length`, and that single difference produces two distinct failure modes. ## forEach: length cached, presence checked `Array.prototype.forEach` reads `length` once at the start. Then for each index from `0` to that cached `length - 1`, it checks whether the index is actually present, and only then calls your callback. Removing during the loop: ```js const a = ['x', 'y', 'z']; a.forEach((v, i) => { console.log('visit', v); if (v === 'x') a.splice(i, 1); }); // visit x, visit z // a is now ['y', 'z'] — 'y' was never visited ``` At `i = 0` the callback sees `'x'` and splices it out. `'y'` slides down into index 0, `'z'` into index 1. The loop moves to `i = 1` and finds `'z'` there — `'y'` was skipped entirely. At `i = 2` nothing is present, so that iteration is skipped silently. This is the classic "filter by splicing" bug: run it over a list where every other element matches and you remove exactly half of what you meant to. Appending during the loop: ```js const b = [1]; b.forEach((n) => { if (n < 3) b.push(n + 1); }); console.log(b); // [1, 2] — the pushed 2 is never visited ``` The cached length was 1, so the loop is over after one call. No infinite loop, but also no processing of what you added. Holes behave the same way as removals: `forEach` skips indices that are not present, so `[1, , 3].forEach(...)` invokes the callback twice, not three times. ## for...of: length re-read every step `for...of` over an array uses the built-in array iterator. Each `next()` compares the current index against the array's `length` **as it is right now**, and if the index is in range it reads that index. Removing: ```js const c = ['x', 'y', 'z']; for (const v of c) { if (v === 'x') c.splice(0, 1); console.log('visit', v); } // visit x, visit z — same skip, and the loop ends early ``` Same shift-and-skip, and because `length` shrank the loop also stops sooner than you expect. Appending: ```js const d = [1]; for (const n of d) { d.push(n + 1); } // never terminates ``` This is the sharp difference. The iterator asks again each step, `length` keeps growing, and the loop runs until the process dies of memory exhaustion. A `forEach` written the same way just quietly does one pass. Also note `for...of` *reads* holes rather than skipping them, so `for (const v of [1, , 3])` yields `1, undefined, 3`. ## Doing it correctly **Iterate a copy.** Cheapest to read, and correct for both loops: ```js for (const item of [...items]) { if (shouldRemove(item)) items.splice(items.indexOf(item), 1); } ``` **Build a new array instead of mutating.** Usually the right answer, and it says what you mean: ```js const kept = items.filter((item) => !shouldRemove(item)); ``` **Walk backwards with an index loop.** When you must remove in place — because other code holds a reference to that exact array — going backwards means a removal only shifts elements you have already passed: ```js for (let i = items.length - 1; i >= 0; i--) { if (shouldRemove(items[i])) items.splice(i, 1); } ``` **Collect then remove.** Gather the indices or items in the loop, apply the changes afterwards. Verbose but obvious under review. ## Why this shows up in interviews It is a bug with no error message. The array ends up *nearly* right, so tests written on small fixtures with a single match pass, and the defect only bites on data where two matching elements are adjacent. Being able to explain the cached-length-versus-re-read distinction shows you know these constructs mechanically rather than as interchangeable syntax — and the practical takeaway, "don't mutate what you're iterating; produce a new array," is the kind of rule a reviewer can actually apply.