My guess is that they want you to declare map/array arguments as "inout" to be able to add/change things so that the changes are visible by caller. It might not be a bad idea after all.
That makes some, but not much sense to me. Firstly, that is not what I read in the book "The Swift Programming Language":
"Whenever you assign a Dictionary instance to a constant or variable, or pass a Dictionary instance as an argument to a function or method call, the dictionary is copied at the point that the assignment or call takes place."
Even if I assume that that is an error (they didn't think of inout arguments when writing that), the behavior still doesn't make much sense to me.
Say that I want to do a few things with someObject.someField.someDict. In most languages, I would introduce a helper variable: var items = someObject.someField.someDict and do items[42] = 346; items[423] = 356; etc. That won't work, as it clones the dictionary (shallowly). I find it is just too easy to accidentally clone arrays or dictionaries in Swift.
That's true in the majority of cases. However, the code could be written as it is for performance reasons. If someObject is a field in the current object, that isn't that bad, especially if it also is an instance of a nested class.
Also, weirdly, that isn't something the language forbids. It doesn't even make it possible for library writers to prevent it.
I still think we will see some language changes before the official release here in this area because naive users will run into too many weird issues with the current behavior.
For example, if the goal is to have normal function arguments immutable, I think it would be more natural to forbid functions from calling mutating methods on their arguments, unless they are specified as inout.
On the other hand, good compiler warnings might be enough for preventing programmers from accidentally copying containers.
