Why can a saved reference into a growable array's storage go stale after later appends?

## What a handle actually names A growable array stores its elements in one contiguous block. Anything you capture that points *into* that block — a raw address, a cursor, a slice, an iterator — is a coordinate in a specific allocation. It is not a claim on the element's identity. That distinction is the whole question. Appending has two behaviours that look identical at the call site: - **size < capacity** — the element is written into an already-allocated slot. Nothing moves. Existing element addresses stay exactly where they were; only any past-the-end marker advances. - **size == capacity** — a larger block is allocated, every existing element is copied (or moved) into it, and the old block is released. *Every* address into the old block is now dangling. Because the second case is rare and invisible, code that captures a handle and keeps appending usually works in testing — the test batch never crosses a threshold — and fails in production on the batch that does. That is the classic shape of this bug: intermittent, size-dependent, and reproducible only above some input volume. ## The review scenario A catalog-ingest routine appends the item it just created, grabs a handle to "the item we just added" so it can patch a field later, then keeps appending the rest of the incoming batch, then writes through the saved handle. Reviewed casually this looks fine — the item is definitely still in the catalog. But one of the appends in between very likely reallocated, and the write lands in the released block. Depending on the environment, that is undefined behaviour, a silent lost update, or a corrupted neighbouring allocation. The failure is not at the moment of invalidation; it is later, somewhere else, which is why these bugs are expensive. ## Index versus reference — a real difference, not a synonym Reallocation copies elements in order, so **element i is still at position i afterwards**. An index therefore survives a move. This makes indices the standard defensive choice for "remember where that item is" across appends. But an index is a *position*, not an identity. Erasing or inserting in the middle shifts every later element down or up by one, and your saved index now names a different item — with no crash and no warning. So the two are invalidated by *different* operations: | operation | index still names the same element | direct handle into the block still valid | |---|---|---| | append within capacity | yes | yes | | append that reallocates | yes | no | | erase before your position | no | no (positions shifted) | | erase after your position | yes | yes | | explicit shrink | yes | no | If you need something that survives both, you need identity: a stable key on the element itself, or a structure whose elements do not move. ## Ecosystems make different messes of this The consequence of a move depends on whether the block stores elements inline or stores handles to them. Growable arrays in C++ and Rust store elements inline, so reallocation physically relocates the objects and a captured pointer or slice genuinely dangles — which is why both ecosystems specify invalidation rules and why one of them enforces them at compile time. Managed runtimes such as those behind Java and C# store references in the block, so the objects themselves never move: a captured element reference stays a perfectly valid object. The bug there is quieter rather than absent — your reference is now *decoupled* from the container's slot, so mutations through it and mutations through the container can diverge, and a saved position can name a different element entirely. Same conceptual hazard, two very different failure signatures. ## How to write it correctly Four options, in rough order of preference: 1. **Do not hold the handle across appends.** Restructure so the field is set before the element is appended, or re-derive the position after the loop finishes. 2. **Hold an index**, and be explicit that it is only valid while nothing is erased or inserted before it. 3. **Pre-size the storage** for the whole batch, so no reallocation can occur inside the window. This is a real technique but a fragile guarantee — it depends on the estimate being an upper bound, and a future edit that appends one extra element silently reintroduces the bug. 4. **Use storage with stable element addresses** — segmented or node-based structures that never relocate live elements — when addresses genuinely must outlive the container's growth. ## What to say in the room "The handle names a slot in the block that existed when I took it. An append that crosses capacity allocates a new block, copies everything and frees the old one, so the handle is dangling. Indices survive that move because order is preserved, but they do not survive an erase before them." That answer shows you understand *why* the rule exists rather than having memorised a list of invalidating operations.