Swift arrays are too swift for our own good
blog.human-friendly.com
blog.human-friendly.com
It helps to think about Swift's let as C++ const and how it maps to library data types, not as ML's let.
Given that the target audience are Objective-C, C and C++ developers, I don't think it is too bad of an option.
let works differently for structs and classes which if fine and clear as it is the main difference between them. Dictionaries are like structs truly immutable when declared with let. Arrays declared with let on the other hand have a complicated partial mutability and copy on write combination that depends on whether the operation changes their length.
I've got another post that is a work in progress that shows some of the behaviour I find odd. When I've finished it I'll add it to the blog properly but I don't mind people seeing and commenting on it as long as they know it is a WIP:
Currently I don't find it a big issue, however the language is still not final, maybe this can still change.
I imagine Apple might still act on some initial feedback before Swift 1.0 gets released.
I imagine the point is to have a low level type describing an area of contiguous mutable memory, rather than expecting people to use arrays everywhere. Not that I know anything about Swift of course.
Array when mutable acts like a list: items are indexed by an integer, and you can replace, add, and remove items.
Array, when immutable acts like an area of contiguous memory: items are indexed by an integer, and you can replace items.
Dictionary, when mutable, acts like a map: items are indeed by key, and you can replace, add, and remove items.
Dictionary, when immutable, acts like a read-only map: items are indexed by key. You cannot add, remove or even replace items.
That is inconsistent. I think they would be better of adding List as a third container type, and changing Array to a fixed size (at creation time) container. Immutable Lists and immutable Arrays would behave exactly the same, but I don't see that as a problem.
On top of that, they chose to make Arrays and Lists value types, (prematurely?) optimized Arrays (but not Dictionaries) to copy-on-write their data, and decided to make that manual copy-on-write (to ensure that an Array is yours and only yours, you have to call unshare on it)
My disclaimer is that I only read the ePub that Apple provided, and somewhat partly so.
It was a tradeoff, for which they provide functions (unshare and copy) for opting out of the default behavior if you so choose.
You aren't hamstrung here. In fact, this Array behavior is going to be absolutely great for manipulating image and other fixed buffer operations. It's a week in, what looks like a wart today can be a great feature in the future.
I guess,you'd be able to do faster & more memory efficient slicing with fully immutable arrays and not be required to think as much about where and how you're modifying an array, but other than that the current implementation seems just like a native C array to me that is only referenced via pointers.
If I'm not mistaken, however, full immutability would lead to higher memory consumption in case of array modifications. Given that Swift was started in 2010 when the iPhone 4 had a mere 512MB of RAM, and that it's targeted at mobile devices, this seems like a good reason to limit memory consumption here.
Any time you pass an array as an argument you have to expect that it may be modified (so you must copy it if you still need the array as it is). Every time you return an array you have to expect that it can be altered so again you need to copy it if you still need it. Given this immutable arrays may let you use less memory because they would only need to copied when they were written to not as a precaution when they are passed as arguments.