

Swift arrays are too swift for our own good - josephlord
http://blog.human-friendly.com/swift-arrays-too-swift-and-flexible-for-our-good

======
pjmlp
What all these discussions miss is that what is immutable is the variable, not
what it points to.

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.

~~~
sbmassey
Ocaml arrays are in fact mutable in the same way as Swift arrays. In fact, if
I recall right, Ocaml ref's are implemented as single item arrays.

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.

~~~
Someone
The problem I have with Swift is that Apple minimized the set of containers.
There are only two: Dictionary and Array.

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.

------
jcizzle
It's really not that big of a deal.

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.

------
th0br0
Why should fully immutable arrays be more performant/better than those with
fixed length?

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.

~~~
josephlord
My problem with it is how confusing the default behaviour is. As I say it is a
perfectly reasonable datatype but in my view a misuse of let to create it.

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.

------
masters3d
How about a full implementation of tupples() for constant lists? Just disable
var for tupples and they would act just like python's. (or something along
those lines)

------
duarose
I don't know Swift, but ... use a vector?

