Swift Access Controls are like C's (and that isn't necessarily a bad thing)

Apple introduced access controls to Swift with the release of Xcode 6 Beta 4 and accompanying documentation (revision history).. The approach they have taken contrasts strongly with that taken by languages like C++, C# and Java in that the controls do not limit access based on the class hierarchy but instead limit based on the file and module.

Even variables declared private can be accessed from other classes and functions that reside within the same file. This allows properties and functions to be declared private but still accessible to free functions and operators defined particularly to operate with that class. It avoids some of the complexity that has C++ having "friend" classes and functions.

Swift Arrays - Beta 3 (Hooray!)

I should probably have written this sooner as it has been 10 days since Beta 3 was released, but I've only just noticed that there is a bit of traffic still coming in about Swift Arrays from my earlier posts about the array semantics in the first Swift betas. The short version is that I'm very happy with the new Swift Arrays in Beta 3 which have full value semantics (optimised with copy on write under the hood). The syntax for declaring arrays has also changed which is fine although I didn't have a particular problem with the old syntax. Be sure to update the Swift iBooks (delete and download again) as there are some significant changes.

The copy() and unshare() functions are gone because unshare has essentially become the default behaviour (although contents changes not just length changes now trigger the copy so copy is not needed either).

Semantic Changes

  1. Arrays are no longer reference types. You can treat every assignment, argument pass and function return as if it were a copy.
  2. Changing the contents of an array is no longer permitted when the array is declared constant with let.

In this example you can see the copy-on-write (CoW) behaviour using the identity operator (=== which I wouldn't recommend you doing in real code to affect behaviour on the CoW status but it enables us to observe the CoW). In the example it doesn't make any difference if a is declared with let or var but b must be declared as var otherwise you will get a compile time error because the contents change.

    Swift Arrays - Will be fixed in future betas - Reference semantics like dictionaries

    Just seen the announcement on the developer forum from Chris Lattner (link for registered developers and another).

    If you want to know about the array issues in Beta 1 see the threads above or my last two posts.

    I don't know and I don't really care if it was always the plan or is a result of feedback. I think this is very good news.

    I think that this means that it will be copy on write behaviour so that if you aren't changing the array you get pass by reference performance and only pay the call by value price when a mutation will occur. It may even be smart enough to know when the caller isn't going to access the array again and allow it to pass and mutate the original. We'll see in beta 3 (or maybe later).

    Swift Arrays - The Bugs, the Bad and the Ugly (and a best practice suggestion)

    UPDATE 2: I've added a new post about the changes in Beta 3 (I like them)

    UPDATE: Apple have indicated that the array behaviour in Swift is going to change - see this post

    My previous post suggests an explanation for why the behaviour of Swift Arrays is as it currently (in the very first Swift release) is as it is. In this post I intend to explain the behaviours, show the problems and give examples. Many examples are based on those found in this thread on the Apple Developer forums. Feel free to add comments if I've missed any categories and I'll incorporate them if they form a different case.

    The relevant part of the documentation covers most of the behaviour and apart from the issues specifically mentioned in the Bugs section at the bottom these are descriptions of the specification not just the implementation.

    Is it Value? Is it Reference? No its Confused!

    Swift Arrays - Too Swift and flexible for Our Good

    UPDATE 2: I've added a new post about the changes in Beta 3 (I like them)

    UPDATE - Apple have indicated that the array behaviour in Swift is going to change - see this post

    Update 3: Please note that this article remains for the historical record and to ensure that links in other articles aren't broken but that the behaviour of Swift arrays was radically changed in Beta 3 and it resolves most if not all of the issues that I had with Swift arrays making the following essentially redundant. Update 2 above links to my follow up article reviewing the changes. You can also read several of my more recent articles about Swift. [This presentation about optimising Swift is particularly recommended and this article about mutating Swift arrays from multiple threads is on topic with this post. - Update 4]

    I really like Apple's new Swift language. It brings in some of the best features of many functional languages including ML, to Haskell such as type inference, strong types, generic types and combines them with with an object system that can interoperate with the existing frameworks while still being fast and efficient. It encourages immutable values over variables and will eliminate whole classes of errors related to null pointers and improper handling of them.

    The main thing that I don't like about it is the handling of "immutable" arrays. For performance reasons when an array is declared with "let" it means only that the array length is immutable and other arrays cannot be assigned to the same variable. You can however change any of the values in the array. I think that almost whatever the performance gains this is not worth the confusing behaviour that results. [Edit: Follow up post explaining the current behaviour is now available.]

    In the post I will mix speculation and a little investigation of the behaviour to understand what the current behaviour is and the rationale for it. I also intend to propose a way out of the situation by which the behaviour could be changed with minimum disruption. Apple has indicated that source compatibility is not guaranteed to be maintained and I think automatic conversion would be possible to migrate code.