Swift: Not quite there, but too far gone too

Re:Swift: Not quite there, but too far gone too by josephlord on Wednesday June 04, 2014 @03:01PM (#7847453)

> Except that you can still make changes that don’t affect length (immutArray[3] = "Whoopsie")

That sounds like a bug to me. I would expect the compiler to detect it as an error (it doesn't). Can anyone point me to the relevant bit of the spec that says you can do that?

[ Parent | on HN ]

Re:Swift: Not quite there, but too far gone too by cosn on Wednesday June 04, 2014 @03:37PM (#7847640)

"Immutability has a slightly different meaning for arrays, however. You are still not allowed to perform any action that has the potential to change the size of an immutable array, but you are allowed to set a new value for an existing index in the array. This enables Swift’s Array type to provide optimal performance for array operations when the size of an array is fixed."

https://developer.apple.com/library/prerelease/ios/documenta...

[ Parent | on HN ]

Re:Swift: Not quite there, but too far gone too by danudey on Wednesday June 04, 2014 @05:03PM (#7848292)

So immutability is a code safety feature, except in the case of arrays, where it's a performance optimization. That seems counterintuitive.

[ Parent | on HN ]

Re:Swift: Not quite there, but too far gone too by josephlord on Wednesday June 04, 2014 @06:08PM (#7848713)

Thanks. I think it sounds like a bad decision, it can be compile time checked so won't cause performance issues. I wonder what the cost is in the mutable case for the fact that the length can vary.

[ Parent | on HN ]