4 ms·
I'm not sure how the behaviour isn't uniform (unless you are getting on to classes). Taking your example assuming x has been declared let x = [1,2,3] then the
by josephlord 12y ago
I'm not sure how the behaviour isn't uniform (unless you are getting on to classes).
Taking your example assuming x has been declared let x = [1,2,3] then the code you show will behave exactly as if the array had been copied but underneath it would actually be sharing a single bit of memory and have skipped/postponed the copies.
If the next line was b[0] = 5 then a copy would be made so x and a would still be [1,2,3] and b would be a separate array [5,2,3].
The behaviour will be exactly the same as copy on assign. You might be able to identify that it hasn't copied with the identity operator === but why would you need to know?
- tel 12y agoI'm assuming this is true var a = [1,2,3] var b = a b[0] = 10] > a [10,2,3] and so copy-on-assign only applies when assigning an immutable reference to a mutable one.
- josephlord 12y agoNo a has the value [1,2,3] still in that scenario. Copy on assign semantics is for constants and mutable variables. Just tested in the playground: var a = [1,2,3] var b = a a == b // true a === b // true b[0] = 10 a // [1,2,3] b // [10,2,3] b[0] = 1 a == b // true a === b // false a // [1,2,3] b // [1,2,3]
- tel 12y agoAh! Cool! My original point was always supposing that held. Being that it doesn't then I agree with Swift being consistent here. Observing sharing using (===) is still dangerous, but presumably that can be saved by wrapping it in sufficient warning.
- josephlord 12y agoI wouldn't recommend using === in production (except for objects of classes) either but for this demonstration it let me show the copy on write without going to assembly. Glad we've reached a common understanding, I wasn't quite sure that I hadn't missed something.