Hacker News new | past | comments | ask | show | jobs | submit login
Swift arrays are too swift for our own good (human-friendly.com)
9 points by josephlord on June 9, 2014 | hide | past | favorite | 11 comments



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.


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.


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.


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.


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


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.


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.


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.


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.


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)


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: