Swift arrays are too swift for our own good

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

by josephlord • 12 years ago

9 11 12 years ago

th0br0• 12 years ago

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.

josephlord3• 12 years ago

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.

pjmlp2• 12 years ago

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.

josephlord3• 12 years ago

I think the audience for Swift is probably wider and anyway there is definitely inconsistency.

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:

http://blog.human-friendly.com/J45WpUpm8vqndCJAHgS7J7kZ

pjmlp2• 12 years ago

I lack proper Mac access (the ones at work cannot be upgraded), but I have watched all WWDC videos and the ebook.

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.

sbmassey• 12 years ago

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• 12 years ago

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.

josephlord3• 12 years ago

Yes, if the Swift had a strong first class list type it wouldn't be a problem but arrays and dictionaries are the only built in collection classes provided.

duarose• 12 years ago

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

jcizzle• 12 years ago

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.

masters3d• 12 years ago

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)

Swift arrays are too swift for our own good

Related Stories