What to Expect From Swift 3

You probably know that Swift 3 is coming later this year. It is the first release that incorporates the hard work of a fantastic community. Dozens of proposals were submitted since Apple open sourced Swift in 2015 and dozens were accepted after careful consideration by the core team. In this article, we take a look at some of the important changes in Swift 3.

What Is Swift 3 About?

The core team has a very clear goal in mind with the release of Swift 3, creating a solid foundation for the Swift programming language. At WWDC 2016, Chris Lattner emphasized that Swift 3 introduces a range of breaking changes with the intent of getting the fundamentals right. That is the common theme of the upcoming release. This means breaking existing features, removing some features, and improving the foundation of the language.

The Swift evolution project has been a true success story for everyone involved in the Swift community. The engagement has been tremendous and the result is Swift 3. Apple is transparent about the release process and snapshots of Swift 3 are available from the Swift website and included in Xcode 8, which is in beta at the time of writing.

More Than Swift

The Swift 3 release not only focuses on the Swift programming language, it also includes substantial changes to the toolchain, the standard library, and the language's interoperability with Cocoa. Remember that Swift is more than a language. When we talk about Swift, we generally only think about the language, but it also includes the standard library and the package manager.

Source Compatibility

If you have worked with Swift, then you know that migrating a codebase from one version to another is no small feat. Unfortunately, migrating a project to Swift 3 will be no different.

That said, the primary goal of Swift 3 is to make sure the transition from Swift 3 to future versions of the language won't be like that. Source compatibility is a key focus point of Swift 3.

Awesomeness

Swift was designed to be a modern programming language, but it was equally important to create a language that looked nice and was ... well ... awesome. With Swift 3, the team continues to "optimize the language for awesomeness" as Chris Lattner puts it.

While there are many breaking changes, the net result is a language that feels and looks great. Swift 3 is a joy to use. The changes to Core Graphics and Grand Central Dispatch, which we discuss in a moment, are fine examples.

What Is Changing?

Enough about how awesome Swift is and how much more awesome Swift 3 will be. In the remainder of this article, I would like to focus on some of the key changes introduced in Swift 3. Keep in mind that Swift 3 continues to evolve until the official release later this year.

API

Readability

A lot of time and energy was spent on improving the API of the Swift language. The changes are significant, there is no denying that. But the result is very, very nice. With Swift 3, the core team aims for an API that focuses on readability and accessibility.

While many of us have become used to the verbosity of Objective-C, the new Swift API takes a different approach by only emphasizing and focusing on the essentials. Take a look at the following example of Swift 2.2.1. This example should look familiar if you have spent some time with Swift ... or Objective-C.

parentViewController.presentViewController(newViewController, animated: true, completion: nil)

In Swift 3, this code snippet looks slightly different as you can see below.

parentViewController.present(newViewController, animated: true, completion: nil)

The Swift community realized that there is no need to include a reference to what is about to be presented since that information is already included in the first parameter. As a result, the method name becomes more readable and more concise. A definite improvement if you ask me.

This is a common thread in Swift 3. Several of the proposals that were accepted and included in Swift 3 focus on simplification and removing cruft from the language. The Swift API was initially heavily influenced by the verbose nature of Objective-C. Readability is great, but Swift 3 cuts back on verbosity without compromising readability.

The Swift community is of the opinion that the design of an API should always take the use of the API into account and that is clearly visible in the changes that are introduced in Swift 3. I am sure you agree that the revamped API looks—and reads—great.

Labeling Parameters

Another important change many developers welcome is the consistent signature of function and methods by including the first parameter label by default. This is what a typical function looks like in Swift 2.2.1. By default, the first parameter label is omitted when the function is invoked.

func setupView(view: UIView, withConfiguration configuration: Configuration) {
    // ...
}

setupView(view, withConfiguration: configuration)

That is no longer true in Swift 3. The first parameter is no longer given a special treatment, which is a very welcome change.

func setupView(view: UIView, withConfiguration configuration: Configuration) {
    // ...
}

setupView(view: view, withConfiguration: configuration)

Because of this change, you could further improve the above example by omitting the reference to the view in the function name.

func setup(view: UIView, withConfiguration configuration: Configuration) {
    // ...
}

setup(view: view, withConfiguration: configuration)

Import as Member

Working with C APIs in Swift has always looked and felt clunky. Core Graphics functions, for example, are imported as global functions, which isn't a great solution and, as a result, using Core Graphics in Swift doesn't feel great.

The same applies to Grand Central Dispatch. In the next example, we use Grand Central Dispatch to asynchronously dispatch a task to a background queue.

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0)) { 
    // ...
}

In Swift 3, the API feels much more like a native Swift API. Functions are imported as methods, which results in the following syntax in Swift 3.

DispatchQueue.global(attributes: .qosBackground).async { 
    // ...
}

Removing Features

The Swift community also agreed on the removal of a number of features, some of which have sparked a few heated discussions. I would like to point out four of them.

C-Style for Loops

Does this look familiar to you?

for (var i = 0; i < 5; i++) {
    print(i)
}

C-style for loops are no longer available in Swift 3. Wait. What? Why? That is a very good question. You can read the proposal, submitted by Erica Sadun, on GitHub. This brings us to the next controversial change.

Say Goodbye to ++ and --

Soon after open sourcing Swift, Chris Lattner, the creator of Swift, submitted a proposal to remove the increment and decrement operators from the language. In his proposal, he mentions that these operators were added, "without much consideration", early in the development of Swift. To clean up the Swift API and avoid any confusion, ++ and -- are no longer available in Swift.

var a = 0
a++

Don't panic, though. The solution is simple. No need to fret.

var a = 0
a += 1

No More var Parameters

If you are familiar with functions in Swift, then you know that the parameters of a function are constant by default. You can change this behavior by prepending a parameter name with the var keyword. For variable parameters, a variable copy of the parameter is passed to the function.

But how does this differ from parameters marked as inout? Right. That is exactly what many of us have been wondering and it is the motivation for removing variable parameters from the language.

From the perspective of the function, there is no difference, that is, the function receives a mutable local copy of the parameter's value. As the name implies, however, a parameter marked as inout writes its value back to the original variable.

To avoid any confusion, var parameters are no longer available in Swift 3. Fortunately, inout parameters are here to stay.

Speaking of inout parameters, in Swift 3, the inout keyword is integrated in the type syntax of function parameters. Take a look at the following examples to better understand this change.

// Swift 2
func combineStrings(inout first: String, second: String) {
    // ...
}

// Swift 3
func combineStrings( first: inout String, second: String) {
    // ...
}

Implicit Tuple Splat Behavior

Even though Swift is still very young, there are many features that are pretty advanced. Did you know that you can pass a tuple to a function instead of a list of parameters? There is no need to cheer, though. This feature is going to be removed in Swift 3.

// Pass Arguments As Separate Arguments

let view = UIView()
let configuration = Configuration()

setupView(view, withConfiguration: configuration)

// Pass Arguments As Part of Tuple

let tuple = (view, withConfiguration: configuration)

setupView(tuple)

Chris Lattner refers to this behavior as "cute" in his proposal to remove the feature. While this behavior can be useful from time to time, it seems to have quite a few consequences. The reason for bringing up this proposal is to highlight the main goal of the core team, simplifying the syntax and the API of the language.

I can see how this feature looked neat at first, but, as the language grew, gained in complexity, and more people started using it, features like this are adding limited value to the language in exchange for what seems to be a list of complications, including performance issues during compilation and complexity to the type checker that could be avoided by omitting the feature.

What Is the Deal With Swift 2.3?

Last week, I wrote about Xcode 8. In that article, I mentioned that Xcode 8 supports both Swift 2.3 and Swift 3. But what is Swift 2.3 and how does it compare to Swift 2.2?

Swift 2.3 is a minor but important update to Swift. The main difference with Swift 2.2.1, the version included in Xcode 7.3.1, is compatibility with the SDKs for Apple's new operating systems, iOS 10, tvOS 10, watchOS 3, and macOS Sierra (10.12).

This means that you can use and build against the new SDKs without making the jump to Swift 3. With Xcode 8, you can submit applications to the App Store using Swift 2.3 or Swift 3. The Swift team knows and understands that the migration to Swift 3 has a significant impact on existing projects that include Swift. Swift 2.3 makes sure you can migrate your projects when you see fit.

Tools

What I also like about the Swift project is that the tools are developed alongside the language. This means that the tools also receive a substantial update when Swift 3 is released later this year.

Documentation

During WWDC, we already saw a glimpse of the changes made to the documentation. While this may seem trivial, have you ever considered how much time you spend browsing the documentation? I have a soft spot for details like this and appreciate the effort the team has put into making the documentation more accessible. The changes are even more dramatic in Xcode 8 as I wrote last week.

Xcode

For now, the vast majority of Swift developers use Xcode as their workhorse. This may change in the future as the language gains traction on other platforms. Didn't Google have plans to use Swift on Android?

In Xcode 8, the integration of Swift is much improved. Navigating the standard library, for example, is more intuitive. In one of the sessions of WWDC 2016, Ewa Matejska illustrates how the synthesized interfaces are now more intuitive and easier to understand. This makes browsing the standard library less daunting.

This brings us to compilation and optimization. You may have heard of whole module optimization. This feature is now enabled by default in Xcode. It impacts application performance and Apple recommends to have this feature enabled in production. If you want to learn more about whole module optimization, I recommend reading this article by Keith Harrison.

While whole module optimization increases compilation time when you first build a project, the results are more than worth it. Subsequent builds are less impacted thanks to incremental compilation.

Conclusion

Swift 3 is a major milestone for everyone involved in the Swift community. Even though nobody likes breaking changes, the direction the language is taking is becoming more clear, making the platform more robust and ready for future changes without compromising source compatibility.

In this article, I highlighted a few of the more important changes that you can expect in Swift 3. For a comprehensive list of the changes, I encourage you to visit the migration guide on the Swift website.

You can also visit the Swift evolution project on GitHub to read more about the proposals that have been accepted and the ones that are still being worked on. Don't be scared. The proposals are often easy to understand. In fact, the goal of the Swift evolution project is for everyone to be able to add to the discussion. What is stopping you?