Yes, but: > unless you expect them to be mutated by other code down the line and are guarding against side-effects Sometimes you hand off a mutable object to

Yes, but: > unless you expect them to be mutated by other code down the line and are guarding against side-effects Sometimes you hand off a mutable object to some other code and that code mutates it for its own purposes. If you hand the same object to multiple functions in this case, they'll all see each other's changes and if this wasn't intentional then voila, you've got a bug. This is one motivation for immutable data structures: you don't have to worry about whether an object might get mutated so you don't have to eagerly clone it. But in an existing codebase it may not be a trivial thing to simply introduce immutability. This is why, instead, I suggested making that defensive cloning explicit and decoupled from the rest of the logic.