Swift 3.0 Upcoming Changes

Posted on December 3, 2015

It finally happened, today Swift has been opensourced and it’s available on GitHub.

And with its public release of the source, the first informations on what will be included in the next major release, Swift 3.0, are finally available.

From now on, everything related to the evolution of the language will be tracked through the aptly named Swift-Evolution repository on GitHub.

Proposals for updates to the language (in the form of new features or alterations to the current behaviour, that will come from Apple or the community) will be discussed following the Swift Evolution Process on the dedicated mailing lists, and Apple will review each proposal and ultimately decide what will be accepted or rejected.

At the moment, Swift 3.0 is planned to be released in the fall of 2016.

The update will focus on a few key areas:

  • ABI Stabilization: Stabilize the application binary interface (ABI) to guarantee binary backward compatibility. This will involve the stabilization of core details of the language implementation like function calling conventions and internal language objects name mangling.

  • Language refinement: Even if the language is still in its infancy, the next releases will start to make the language more consistent outlining a set of core principles that define the language and eliminating features that deviate from those principles.

  • Improvements to generics: The work on generics will reach completion and some known gaps will be filled.

  • Type system cleanup and documentation of behaviour

  • Complete the alignement of core libraries to the API guidelines

No updates related to new concurrency primitives or C++ interoperability will be included in the next major release, but these are among the new features that will be available in future releases.

Regarding the actual changes coming with Swift 3.0, for now we know that a few proposals have been accepted and will be included:

Better Translation of Objective-C APIs Into Swift

The automatic translation of Objective-C APIs will be improved to adhere more strictly to what is described in the Swift API Design Guidelines, so, as you imagine, more than a few method names will change.

To give you and idea of some of the changes, the translator will drop the NS prefix from all Foundation classes, boolean properties will gain an is prepended to their name (e.g. a boolean empty property will become isEmpty) methods will lose redundant portions of their name (e.g. UIBezierPath.moveToPoint(p : CGPoint) will become UIBezierPath.moveTo(p : CGPoint) and methods like UIBezierPath.bezierPathByReversingPath() will simply become UIBezierPath.reversing()).

Removal of currying func declaration syntax

To simplify the language, removing some rarely used syntactic sugar, Swift 3.0 will lose the curried function declaration syntax (e.g. func foo(a:Int)(b:Int)). Not a big loss in my opinion.

Removal of var from Function Parameters and Pattern Matching

It will not be possible anymore to create local mutating copies of function parameters or binding variables inside if/switch/guard/for/etc… using the var keyword. Thus, no more implicit variable shadowing will be performed, and that’s a good thing.

To give you a practical example, this will not be valid Swift 3.0 code:

if var x = getOptionalInt() {
  x += 1
  return x

But something like that could be easily updated this way, introducing a new temporary variable:

if let x = getOptionalInt() {
  var x = x
  x += 1
  return x

Removal of the ++ and – operators

The unary increment and decrement operators will be completely removed. Implemented only by a few types, prone to be implemented with some non-obvious implicit behaviour, and prone to encourage the implementation of some overly “clever” code.

And that’s all for now.

The list of features is obviously not complete yet, more proposals will be discussed and accepted in the following months. I’ll keep and eye on Swift-Evolution and the mailing-list to follow the progress of the release.



The first proposal from the community has been accepted, there will be no more c-style For (the good old indexed for) in Swift 3.0 (a warning will be displayed in Swift 2.2). A lot of additional modifications are being proposed on the mailing list, I recommend to check it out, there are many discussions that detail the rationale behind current language choices, explanations you will not find anywhere else.


Read an interesting interview to Craig Federighi about the future of open source Swift.

After just one day, more than a few additional proposal for modifications are already being discussed on the specific mailing list (archive here) and proposal documents are starting to appear on github.

Did you like this article? Let me know on Twitter!

I'm also on Twitter and GitHub.

Subscribe via RSS or email.