Immutable Data or Copy-on-Write¶
Method — instantiates Declared Effect Boundary Enforcement
Prevents accidental mutation by making default state reads non-mutating and requiring explicit creation of changed versions.
Immutable Data or Copy-on-Write attacks hidden side effects at their most common source — the shared mutable reference — by removing in-place mutation altogether. Its defining move is about how state changes, not which operation is allowed to change it: existing values are never modified in place; a "change" always produces a new version, leaving every prior version intact and valid. Two holders of the same data therefore cannot clobber each other, because there is no shared cell to clobber. The invariant "no value is mutated behind someone's back" holds by construction rather than by discipline, which is what makes the method feel less like a rule and more like a law of physics for the data.
Example¶
A collaborative document editor keeps each document as an immutable snapshot. When one author inserts a paragraph, the editor does not overwrite the current document in memory; it constructs a new version that shares all the unchanged structure with the old one and differs only at the edit. The prior version still exists, unchanged, and any reader still holding it sees exactly what they saw before.
Now two authors edit concurrently. Under a shared mutable buffer, one's write would silently stomp the other's — the classic hidden-mutation bug. Here, each edit derives a new version from a known base, so neither can corrupt the other's in place; reconciling the two becomes an explicit, visible step rather than a race nobody observes. And because applying the same edit to the same base always yields the same new version and never disturbs the base, a retry after a dropped connection is harmless — it simply reproduces a version that already exists instead of doubling an effect.
How it works¶
- No in-place write. The default operation on a value is a read that changes nothing; there is no path to modify an existing value where it sits.
- Change as new version. Producing a changed value means constructing a new version, explicitly, so every mutation is a visible act rather than an incidental one.
- Structural sharing. New versions share the unchanged parts of old ones, so immutability stays affordable instead of copying everything on every edit.
- Retry-safe by construction. Because operations neither accumulate on nor disturb a shared cell, re-applying one reproduces the same result rather than compounding an effect.
Tuning parameters¶
- Sharing granularity — whole-value copy versus fine-grained structural sharing. Sharing saves memory and time; naive copying is simpler but costly on large state.
- Version retention — how long old versions are kept before collection. Longer retention aids history and rollback; shorter frees memory sooner.
- Enforcement level — language-guaranteed immutability versus a "don't mutate this" convention. Guaranteed immutability cannot be bypassed under pressure; convention can.
- Copy-on-write trigger — copy eagerly at hand-off, or lazily on first write. Lazy copying avoids work for readers that never mutate.
When it helps, and when it misleads¶
Its strength is eliminating a whole class of bugs at the root: with no shared mutable state, accidental cross-contamination, aliasing surprises, and stomped concurrent edits simply cannot occur, and retries and speculative reads become safe.[n1]
Its failure mode is that it relocates cost rather than removing it — the effort shifts to version management, memory pressure, and garbage collection, and a deep object graph can be expensive to keep immutable. A subtler trap is shallow immutability: a value that looks frozen but holds one mutable reference reopens the whole hole while advertising safety. The guarding discipline is to make immutability deep and enforced where it is relied upon, and to budget for the version-management cost instead of being surprised by it.
How it implements the components¶
protected_invariant_set— it holds the core invariant "existing state is never mutated in place" by construction, so shared values cannot change behind a holder's back.idempotency_and_retry_rule— because operations produce new versions instead of accumulating on a shared cell, re-applying one is inherently safe, making retries idempotent.
It does NOT implement effect_boundary or mutation_gateway — it changes how state is written (never in place), not which operations may write or through what channel; drawing that read/write line is Command–Query Separation, its nearest twin, which fixes which operations may mutate rather than how mutation happens.
Related¶
- Instantiates: Declared Effect Boundary Enforcement — removes accidental shared mutation so the only changes are the explicit, versioned ones.
- Sibling mechanisms: Audit Log and Trace · Command–Query Separation · Compensating Action Protocol · Effect Contract Annotation · Effect Review Checklist · Permission Scope or Capability Token · Sandbox or Staging Execution · State Diff Test · Transaction Boundary
Editorial Notes¶
Form Classification¶
Form family: Structure, Architecture & Configuration
Rationale: Immutable Data or Copy-on-Write operates as a persistent arrangement of components, resources, interfaces, or technical topology because it prevents accidental mutation by making default state reads non-mutating and requiring explicit creation of changed versions
Independent corroboration: The frozen evidence defines Immutable Data or Copy-on-Write as 'Prevents accidental mutation by making default state reads non-mutating and requiring explicit creation of changed versions', so its operative form is Structure, Architecture & Configuration.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Persistent data structures, immutability, and structural sharing are established programming-language and systems concepts.
Related originating lineages:
- Mathematics — Functional abstraction and value semantics supply formal foundations for treating transformations as new values.
Review resolution: Both reviewers independently assign computer_science as the primary originating domain, so that shared primary is retained. Alternate domains are the union of reviewer-identified formative or independently originating lineages; later application settings alone are excluded. The evidence describes one principal historical lineage. Its defining controls and vocabulary remain bounded to a particular professional or technical practice. The encyclopedia entry generalizes the established mechanism without creating a new composite lineage.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] A persistent data structure preserves all previous versions of itself when modified, so an "update" yields a new version while the old remains usable. Chris Okasaki's work on purely functional data structures shows how structural sharing makes this efficient — the basis for copy-on-write done well. ↩