I do not understand that, either. Also, I find it weird that dictionaries are value types. If I started programming in Swift, I think I would soon have a generic class named 'Dict' that has a single field storing a Dictionary and the same interface as the Dictionary struct.
Does anybody know what is the reason they chose those non-standard behavior for the standard containers?
Isn't that such that you can declare a dictionary or array as constant by using 'let' in the declaration? I think the designers wanted to avoid complicated annotations for constant the way it works in C++. Being able to use 'let' also seems to make collections available for matching in case statements. I recommend watching this[1] tutorial - the way switch/case works in Swift was really impressive to me.
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.
