Some languages refuse to capture a local that is ever reassigned — what does that restriction buy them?

## What the rule actually forbids The restriction is narrower than it sounds. It says: a local variable that a closure captures must be assigned once and never assigned again. It does **not** say the captured data is unchangeable. A variable that holds a handle to a mutable record satisfies the rule perfectly, and every field in that record may still be written by anyone who can reach it. The rule is about the **name**, not about the world the name reaches. That distinction is where candidates most often go wrong, in both directions: treating the rule as a guarantee of immutability, or dismissing it as pointless because mutation still gets through. ## What it buys - **One capture semantics instead of two.** If the variable can never be written after capture, copying the value and holding the binding produce identical observable behaviour, forever. The language no longer has to specify which it does, and the programmer no longer has to know. - **No shared cell.** Because a copy suffices, there is no allocation to make and no indirection on each access. The implementation gets the cheap layout in every case rather than as an optimisation. - **A deferred closure with no surprises.** The class of bug where a queued function reports a value written long after it was captured simply cannot be expressed. Whatever the capture site read is what the body will see. - **Sharing that is visible.** When a closure and its creator genuinely need to share a changing value, the programmer must put an explicit container in the variable and write through it. The sharing is now a declared object someone can find, rather than an ordinary-looking local that quietly became shared. | | Without the rule | With the rule | |---|---|---| | Capturing a reassignable local | allowed | rejected at compile time | | What a deferred read reports | depends on the capture model | the value at capture, always | | Where shared mutable state lives | possibly in a plain local | in a container the programmer declared | | Implementation | a cell when needed | a copy, always | ## What it costs Nothing is free, and the price shows up in three places: 1. **Ceremony for real sharing.** A running total accumulated by a closure across calls needs a declared one-slot holder and a field write instead of a plain assignment. The code says more than the idea does. 2. **Honest programs rejected.** The check is syntactic — is there an assignment to this name anywhere in its scope? — so code that assigns before any closure exists, or on a path that provably never runs alongside the capture, can still be refused. The rule trades a little expressiveness for a guarantee that needs no analysis. 3. **A false sense of safety.** Because the variable cannot be rebound, people describe the captured thing as frozen. It is not, and the record behind the handle will prove it. ## The escape hatch, and why it is the point Every language with this rule leaves one way out: put a container in the variable, capture the container, and write to its slot. Notice that this is the **same object the compiler would have synthesised** in a language without the rule. The difference is purely who writes it down. In one design the box is invisible and every captured local might be shared; in the other the box is in the source, named, and reviewable. That is the whole argument, and it is a design argument rather than a technical one: the two designs can express the same programs, and they disagree about whether shared mutable state should be something you can create by accident. Stating it that way — as a trade of expressiveness for legibility, not as one language being stricter than another — is what an interviewer is listening for.