A team assumes that marking an object read-only protects the whole structure hanging off it. But in C++ a `const` member function can still mutate through a pointer member, and in Swift a struct bound with `let` is deep through nested structs yet stops at the first `class` reference it holds. How deep does a read-only guarantee actually reach in the languages you know, and how would you design an API that hands back nested structures in a language where it does not reach?

## The question is reach, not existence Every read-only mechanism answers "can you change this?" for some set of memory. The interesting design axis is how large that set is. A **shallow** guarantee covers one object's own slots. A **transitive** (deep) guarantee covers everything reachable from that object by following references. Most "but I made it immutable" bugs live in the gap, because the syntax that produces a shallow guarantee looks exactly like the syntax people imagine produces a deep one. ## C++: transitive through members, stops at pointees Inside a `const` member function every data member is treated as const. A member of type `std::vector<T>` really is protected; a member of type `T` really is protected. But a member of type `T*` becomes `T* const` — the *pointer* is const, the *pointee* is not. So a `const` method may freely mutate everything behind its pointers. That is not an edge case: the pimpl idiom puts an entire class's state behind exactly one such pointer, which means `const` says nothing at all about the class's real state. `std::experimental::propagate_const` is a wrapper type whose whole purpose is to push constness through to the pointee; a standards body shipping a fix-up wrapper is the clearest possible admission that the default surprises people. `mutable` is the other escape, but that one is at least written down at the declaration. D is the instructive contrast. Its `const` and `immutable` are **transitive by language rule** — you cannot reach a mutable object through a const reference — and the D designers describe that as a deliberate correction of C++. Same keyword, opposite reach. ## Swift: deep through values, stops at the first reference type Swift structs are values, and values contain values, so `let config = Config(...)` really does freeze the whole nested struct tree: you cannot mutate any field at any depth, and copies are independent. The guarantee ends the instant the graph contains a `class`. A `let` struct holding a `var` class-typed property means you cannot *reassign* that property, but you can mutate the referenced object's properties all day, and two "copies" of the struct share that object. This is the practically important rule of thumb in Swift codebases: value semantics are only as deep as the last struct in the chain. ## Kotlin and C#: read-only is a static view, not a depth claim Kotlin's `List<T>` and C#'s `IReadOnlyList<T>` are interfaces that omit mutators. They constrain *what this reference can do*, not what the referent is: the same backing mutable list can be held elsewhere and changed under the caller, and nothing whatsoever is said about the elements. C#'s `readonly` field has the same shape one level up — it prevents reassigning the field, not mutating the object it points to. Even genuinely persistent collections like `ImmutableArray<T>` are immutable in exactly the shallow sense: the sequence is fixed, the elements are whatever they were. ## JavaScript: the ecosystem answered where the language did not `Object.freeze` covers own properties only. There is no deep-freeze primitive, so every large codebase either writes a recursive `deepFreeze` helper or adopts a structural-sharing library — Immer being the common one, which uses proxies for copy-on-write and freezes its produced results. That the answer arrived as libraries rather than as syntax is itself the point: depth was left to userland. ## The poles Rust sits at one end: immutability is a property of the *access path*, so reading a field through `&T` yields `&Field`, and the whole reachable closure is read-only, checked statically at no runtime cost — with `Cell`/`RefCell`/`Mutex` as named, type-visible opt-outs. Java sits at the other: `List.copyOf` and `Collections.unmodifiableList` fix the spine, and `list.get(0).setStatus(...)` still compiles. ## Why the divergence exists Deep guarantees need either whole-graph reasoning at compile time (Rust's borrow checker, D's type rule) or a runtime walk of the graph (deepFreeze). C++ chose neither, for the same reason it does most things: constness is a property of a declaration, and a pointer's declaration is not its target's declaration. Swift chose deep-for-values because values are copied anyway. Kotlin and C# chose interface subsetting because it costs nothing and composes with existing collections. ## Designing an API where depth is absent 1. **Make the leaf types immutable rather than wrapping the container.** A collection of immutable elements needs no wrapper for element safety; a wrapper over mutable elements is theatre. This is why records, `val`-only data classes, `readonly record struct` and Swift structs all arrived within a few years of each other. 2. **Return a projection, not the domain object.** If the caller needs three fields, hand back a small purpose-built read-only type. The depth question disappears because the returned graph has no mutable nodes. 3. **State the reach in the contract.** "Returns an unmodifiable list" is an incomplete sentence; the honest version says the list cannot be structurally modified and the elements are shared. 4. **Do not model depth by recursing at runtime.** Deep-freezing or deep-copying a large graph per call turns a design problem into a throughput problem, and still misses cycles, lazily materialised slots, and anything reachable through a closure. ## The verdict A wrapper or a `const` is a statement about one node. The element type is what actually protects the data. Ask, of any read-only claim, "how many reference hops does it survive?" — for most languages the answer is zero or one.