Immutability
Updated 2026-08-05
INTRODUCTION
English translation pending.
CORE DEFINITION
A property of data and program state in which a value cannot be altered after it is created, so updates return new values and leave prior ones untouched. Immutable structures make reference transparency possible, since an expression always yields the same result, and they remove the shared mutable state that produces race conditions in concurrent programs. The core claim is that forbidding in-place mutation buys reasoning simplicity and safety at some memory cost. The qualification is that copying carries a performance price, so hot paths may still need localized mutability.
SCAFFOLDING EFFECT
Reduce cognitive load
- Use Default Immutable: Choose immutable types for shared data unless a measured reason exists. - Use Replace Not Edit: Return a new value for each change and keep old references for comparison. - Use Lock Reduction: Rely on immutability to remove races instead of adding locks around shared state.
Anchor fast decisions
Concurrency bugs arise when two execution paths read and write the same memory with no agreed order, so one path sees a partially updated state. If values cannot change after creation, every reader observes a complete and consistent object, and no ordering discipline is required. The cost shifts from coordination to allocation, since each change creates a new structure, and that trade is usually favorable except where allocation dominates.
MINIMUM ACTION
In progress 0/1Practice this model in one real situation:
account_treeGenealogyexpand_more
menu_bookReferencesexpand_more
Source support: Explicit
- en.wikipedia.orghttps://en.wikipedia.org/wiki/Immutable_objectverified
PRIVATE NOTES · Only visible to you
SAVED Q&A
ENTRY Q&A · Private saving available
Ask with a clear boundary
thinkingmodels answers from published entry context only.
Your question is sent to thinkingmodels. The answer uses public entry context only.