Immutable data

An immutable value remains unchanged after construction. A name may later refer to a different value, and the program may maintain changing state elsewhere; the restriction concerns rewriting the old value itself. A calculation holding that value can therefore reason about it without expecting its contents to be silently replaced.

References: [1]

Adding an element yields a new collection while the old collection remains available. Copying everything would be expensive, so persistent structures can share unchanged nodes and rebuild affected paths. Sharing is an implementation technique; the observable promise is that updating one logical value does not mutate another version already in use.

References: [2]

Tasks reading an immutable value need no writer coordination merely to prevent that value changing halfway through a read. The program must still coordinate replacement of shared references and ordering of business actions. Immutability reduces one source of shared-state problems without solving scheduling, external input-output, or distributed consistency by itself.

References: [1]

Retained versions support undo and comparison, but their references keep relevant structures alive. A container can also hold mutable elements, requiring a clear account of how deeply immutability applies. Structural sharing, object boundaries, and retention policy all matter; convenient history does not imply that keeping versions consumes no resources.

References: [2]