An immutable collection never changes after creation. That stability makes shared data easier to reason about: no caller can alter the collection behind another caller’s back. It also avoids unsafe shared modifications that complicate multithreaded code. Kotlin’s functional style favors immutable data and pure functions for these reliability and testing benefits. section 1.2.3 section 1.6
Do not equate Kotlin’s read-only collection types with immutable collections. A `Collection<T>` reference prevents that reference from calling mutation methods, while `MutableCollection<T>` exposes operations such as `add`. Both references can still designate the same mutable object, so code with a read-only view may observe changes made elsewhere. section 8.2.2
Figure 8.5 The Collections interface is read-only. MutableCollection extends it and adds methods to modify a collection’s contents.
The type hierarchy separates read-only access from mutation-capable access: `MutableCollection` extends `Collection` with operations that change contents. section 8.2.2
Accept source data without granting mutation
`copyElements` takes its input as `Collection<T>` and its destination as `MutableCollection<T>`. The signature documents the intended roles: iteration is allowed for the source, whereas adding elements is allowed only for the target. Passing a variable typed as `Collection<Int>` as the target fails at compile time. section 8.2.2
A read-only view is not automatically thread safe. Its underlying collection may be mutable and may be changed concurrently through another reference, causing problems such as `ConcurrentModificationException`. Synchronize access or use data structures designed for concurrent access when necessary. section 8.2.2
For truly immutable Kotlin collections, use `kotlinx.collections.immutable`; the standard library does not provide them. Immutability also matters for data-class instances used as `HashMap` keys: changing key state after insertion can leave the container invalid. Prefer `val` properties, and create a changed copy rather than modifying the original. section 8.2.2 section 4.3.2
Copy instead of mutate
```kotlin data class Customer(val name: String, val postalCode: Int) val bob = Customer("Bob", 973293) val moved = bob.copy(postalCode = 382555) ``` `moved` is a separate instance. Updating it through `copy` cannot affect code that still refers to `bob`. section 4.3.2
