A price-list type documented as immutable returns its live tier-row container from an accessor — which promises to callers are now false?

The leak here is small and the loss is not. Understanding why takes separating the label from the thing the label was selling. ## What the label was selling Nobody asks for an immutable price list because unchangeability is pleasant. They ask because immutability licenses a set of moves that are otherwise unsafe: - A property checked once is still true later, so it need not be re-checked on every read. - Two reads return the same value, so anything derived from one read may be kept and reused. - The value may be handed to another part of the system, stored in a registry, or logged as a record of what was published, with no further defence. Each of those is a licence, and each is issued on the strength of the same claim: nothing reachable from this value can change. Returning the live container revokes the claim, so every licence issued on it is revoked with it. ## The promises, one at a time **Construction-time validation.** Suppose the constructor rejects a price list whose rows are out of threshold order, or whose tiers overlap. That check runs against the rows as they were at construction. A caller who obtains the live container and reorders it has not defeated the constructor — the constructor is simply not consulted again. The invariant is now a historical fact about one moment, and any code reading the value later that relies on sorted rows is relying on something nobody is enforcing. **Cached derived values.** A total, a highest applicable tier, a rendered summary: these are computed from the rows and kept because the rows were supposed to be stable. An in-place write to a row changes the rows without changing any reference, so nothing that could plausibly act as an invalidation signal ever fires. The cache does not become wrong loudly; it becomes wrong quietly, and typically stays wrong until something unrelated forces a rebuild. **Safe hand-off.** A value that cannot change can be given to a second component as-is. A value that can change underneath the receiver cannot, and the receiver has no way to tell the two apart, because both of them look like an immutable price list at the point of hand-off. ## Why one accessor is enough Deep immutability is a universal claim — *no object reachable from this value can be written by anyone*. A universal is falsified by a single counterexample. It is tempting to answer that only the tiers are affected and the rest of the type is fine, and that is true about the fields while being useless to the caller: the caller cannot condition on which sub-part of a guarantee survived, because the guarantee was what they were handed. | Promise callers were relying on | Survives the leak? | Why | |---|---|---| | The root keeps referring to one container | yes | The binding was never the problem | | Construction-time checks hold at read time | no | Rows can be rewritten after the check | | Two reads return the same value | no | An in-place write changes what a read sees | | A derived total stays valid | no | Nothing signals that the rows changed | | The value can be passed on unguarded | no | The receiver holds a changing value | ## What actually survives Be precise rather than dramatic. The fields that cannot be rebound still cannot be rebound. Sub-structures that genuinely are unwritable are still unwritable. What is gone is the single sentence the type's documentation was making, and with it every consequence that sentence was carrying. That distinction matters in a real discussion, because the repair is chosen against what is actually broken rather than against a sense that everything is. ## How this shows up in production The characteristic signature is a bug report about a value that changed with nothing in the history to explain it. There is no reassignment, no new publication, no version bump — just two observations that disagree. Investigation walks the closure of the published value and looks for a reference that escaped, and the accessor is usually where it escaped. The second signature is a cached figure that disagrees with a freshly computed one, which is the same defect seen from the derived side. ## The answer an interviewer is listening for They want the consequences named, not the word *encapsulation*. A strong answer says which licence each caller had been issued, shows that an in-place write produces no observable event, and says plainly that a guarantee about everything reachable cannot survive one reachable thing being writable. Mentioning that a documentation comment is not an enforcement mechanism is a useful closing line; leading with it is not an answer.