Hear about the newest features in Swift 3, the third major release of the safe, fast, and expressive language, and the first major release built with the open source community. Gain insight into the latest changes in Xcode including enhanced migration support to help move your code to Swift 3. Learn how you can get involved in the open source community at Swift.org.
[ Music ]
Welcome to What's New in Swift.
Let's start out by talking about the goals
for the Swift 3 release.
Swift was released as an open source project just six months
ago, and a big part of doing that was not just to shove
out a bunch of sources to GitHub,
but to create a fully open community
that drives the evolution of Swift going forward.
Swift 3 is the first major update to Swift that is intended
to be a product of that community, and so we'll talk
about how that community has evolved and the language,
the evolution process
that crafts the language going forward, and Chris will talk
about what that community has produced for Swift 3.
Another big aspect for this release was bringing Swift
to more people.
Today's software ecosystems are really diverse
and people are doing a lot of different things
in different contexts, whether they are building it
for the server, they are building apps, and others.
We want Swift to be available for everybody, and so we'll talk
about some great things that have happened on the Linux side.
And this is really the first major update to Swift
since Swift was ported to Linux.
Now, looking inward at the release, Swift has been going
through some iterate refinement and sculpting
over the last two releases, based a lot from feedback
from developers who are using it, and also, as you'll see
from the Swift community since it was open sourced.
A big thing about Swift 3 is we really want
to get those core fundamentals into shape, all right,
so we can really build on top of them going forward.
And last, and probably the most broadest goal, is we really want
to awesomize Swift for awesomeness.
Swift is really intended to be a powerful tool in the hand
of developers, and in their hands they can do really
That's what we intended it to be.
Now, this is a really kind of broad goal,
and the way we've been directing our efforts here is listening
to feedback from those using Swift, app developers,
but also how we're using it within Apple.
And so I want to talk a few minutes
about how we've been using Swift, particularly
in the last year in our OS releases and the tools.
Now, the big thing here is it's not just increased adoption
at Apple; it's just we're using Swift in a variety
of different ways, whether it's in writing apps,
we have internal frameworks that are now using Swift,
Agents and Daemons, things that just kind
of power the underlying experiences
in the operating system.
And so if you can look, you know, to Sierra, iOS 10,
you can see things like the New Music app using a significant
amount of Swift.
The Console app in Sierra which is very much tied
to the new logging initiatives, also has a lot of use of Swift.
Also with the Agents and Daemons, the new picture
in picture feature in Sierra is 100 percent written in Swift.
Now, looking to the Tools, Xcode, if you look inside,
it's using Swift as well.
For example, the new documentation viewer
in Xcode 8 is 100 percent written in Swift.
And the new beautiful Swift Playgrounds for iOS,
that's 100 percent written in Swift as well.
So we are really using Swift in many different ways.
And this is really focusing our efforts to solve different kinds
of problems, whether it's performance issues,
such as memory usage, getting the calling conventions right,
and so forth, and just making sure
that Swift is the right tool in different contexts.
I want to talk about a particular case study,
and that's the Dock.
And the Dock is interesting for two reasons.
The first reason is it's a lot more than people think.
It's not just the bar at the bottom of your desktop.
It's actually a large amount of the macOS Windows, you know,
So things like Mission Control, LaunchPad, Spaces,
this is all what we consider part of the Dock.
The second reason why Dock is interesting is it's actually
been a Swift adopter for two releases.
It started adopting Swift in El Capitan.
So we have two releases to look at and to compare
in how it was using Swift.
So a lot of changes happened to the Dock in Sierra.
First, almost all of Mission Control was rewritten in Swift,
and the accessibility engine was rewritten in Swift.
Why did we do this?
We just didn't rewrite code just for the sake of rewriting code.
The code had kind of grown organically over time
as features had been added and it was time to refactor it.
But also some new functionality needed to be implemented,
and so it was the appropriate time to make this,
you know, to do this rewrite.
Now, what does this look like at the project level?
So to give you an idea, Dock is about 200,000 lines of code
with tens of thousands of lines written in Swift.
And between El Capitan and Sierra, the amount of Swift code
in the project more than doubled.
And this actually, because this is part of a rewrite,
this replaced a significant amount
of C and Objective-C code.
And the effects here are somewhat non-linear,
because there's some refactoring
and some new features being added, but we saw there was
about 15 percent less code to replace the existing C
and Objective-C code in Swift,
and this is with new features being added at the same time.
And the net result is this project is actually slightly
smaller in Sierra than it was in El Capitan.
Now, there's a lot you can read into statistics.
I think the most important thing here is the engineers working
on the Dock love using Swift.
They are not mandated to use it.
They really just wanted to use Swift.
And their experience is that they feel
that they can more easily articulate the code
that they want to write and they love the safety features
from Swift that gives them more assurance
that the code they write is great.
Let's move on to Swift Open Source.
If you haven't already, the place to go
on the web is swift.org.
And there you can find a variety of ways that you can contribute
to the project, such as if you want
to do the most awesome profession in the world
and be a compiler hacker, you can check out the source code
and find ways to contribute.
And there's other ways.
You know, you can contribute ideas, where do we want
to take the Swift language?
Now, how we run the project is really important.
It's meant to be very egalitarian.
We want it to be a very open process and transparent
and free, and everyone can really participate
in driving the language forward.
And they can see the rationale of why changes were made.
This is really important.
And so all changes to language, whether you are somebody
who works at Apple or you're someone out there
who is writing apps and you have an idea of how to contribute
to change Swift, it works exactly the same way.
And I think this is really, really important.
And it also means that non-Apple engineers do have direct access,
you know, to commit to the compiler
and all those repositories.
And so we really wanted to empower the community
to drive Swift forward.
Third, and I think this is just as important,
we have a very strong code of conduct for the project,
and we think it's very important that everyone can contribute
without feeling that they are discriminated against or treated
in an unprofessional manner, and we enforce this very strongly.
And last, the project is under a Permissive Open Source License.
This is really important, because we want Swift to be used
in ways that Apple didn't conceive.
This is one of the goals of open sourcing Swift.
We really want everyone to be able to use it in a lot of ways.
And there's strong patent protection
for the community as well.
So that's why we chose this license.
Now, you can follow along with top of, you know,
Trunk Development for Swift in a variety of ways.
You can check out the sources.
You can build the compiler.
We also provide downloadable snapshots regularly,
that you can download from Swift or you can use directly
in Xcode, or you can use them on Linux.
And as other platforms are supported,
we will provide those snapshots as well.
What's really awesome
in an Xcode 8 is we now have full support for Playgrounds
with these downloadable snapshots,
which is a really awesome way to experiment
with the language as it evolves.
Also, you no longer have to restart Xcode if you want
to use one of these tool chains,
so this really creates a really clean experience with trying
out the latest version of Swift.
Now, all the development is happening now on GitHub,
and it's not just one project.
It's actually a family of repositories,
and you can find a description of all of them on swift.org,
but they can roughly be categorized
into these three sections, the Language
and its evolution process, a Package Manager,
and a set of Core Libraries.
Let me talk about each.
Now, the Package Manager was announced
when Swift went Open Source.
It's still very early but active in development.
There's over 1,000 repositories on GitHub
that use the Package Manager.
So what is this?
It's a cross-platform, Package Manager, for building, you know,
packages for Linux, for 0S 10.
The idea is that we want to build, enable the community
to build, a software ecosystem for Swift.
And we think this is really vital for bringing Swift
to other contexts, like Swift on the server.
It's designed for very frictionless development.
It's like easy to get started, minimal configuration,
easy to articulate your dependencies.
It's just -- the idea is just write your code and go.
And we think the Package Manager is so fundamental to Swift
and its long-term success that we are committed
to delivering fantastic integration
of the Package Manager in Xcode as it matures.
Let's talk about the Core Libraries.
So what are these?
There's a lot of great APIs in iOS,
in macOS, TD OS, and WatchOS.
A lot of these are like part of the base substrate of APIs
that we think should be available
for everyone to get work done.
And so the Core Libraries represent alternate
implementations that aren't tied to the Objective-C run time
of some of these core APIs on Linux, and also other platforms
that Swift will be ported to, so notable examples include things
like XE tests, so you can write unit tests,
a subset of foundation that really is quite portable
and not really tied to Cocoa, and a work in progress port
of libdispatch so you can use all those concurrency APIs.
Now, the work here is still fairly early.
It launched with Swift Open Source,
but there's a lot there right now.
So for foundation on Linux, it supports a lot a great APIs
like manipulating URLs, dates, there's data, UID, and so forth.
And we expect this to mature and possibly grow in the future
over time as the community wants more functionality.
Now, let's talk about the Language.
Now, Chris will talk a lot
about specific changes in the language.
I want to talk about the evolution process
that creates those changes.
This happens out on the Swift-evolution repository.
So let's say you have an idea of how you want to change Swift.
Like you think there's something in there that sucks
and some problem there that really gets in the way
of doing core development.
Maybe it was a good design decision two years ago,
but it should be revisited.
Or maybe there's something great that we should add
that would enable a whole new set
of opportunities for developers.
You start the idea by socializing it
on a mailing list, kicking it around with other developers
who have similar interests, and see,
you know, is this a good idea?
What are the pros and cons here?
And once there's enough critical mass,
it gets turned into a proposal.
This is just essentially like a white paper,
written in markdown, which can be viewed, you know,
right in a web browser on GitHub.
And here's an example of actually one of the proposals,
and it gets submitted for review via pull request.
Now, you notice in the bottom left corner here this badge
number, it says SE0046.
Each proposal is numbered, and this is how we refer to,
you know, the actual specific proposals
that created change in Swift.
Chris will refer to these proposals throughout his part
of the talk when he talks about the changes to the language.
And these proposals are the way that everybody proposes changes
to the language, proposes the rationale
of why we're doing the change, you know,
what the specific change would be, the pros and cons,
and once the proposal is accepted,
the rationale for accepting it.
So a formal review for a proposal starts just
by accepting it into the repository,
and the review is really just -- it's open discussion again.
It's on the mailing list, but this time it's focused
to the specific proposal as written,
not just some abstract idea.
And after some period of time, the Swift core team,
which is a small set of individuals, whose role is just
to shepherd the project going forward, looks at the feedback
of the community, sees, you know, the pros and the cons,
and arbitrates a decision based on what the community wants.
And they look at a variety of things.
How does the current proposal fit into Swift?
So does it make sense?
So sometimes proposals are sent back, hey, you know,
the way it currently is, this just doesn't work, you know,
so go back and consider some refinements here.
Or this will just never fit in Swift at all.
But also the proposals are often accepted,
sometimes with refinements.
And any time it's sent back or accepted,
a rationale is documented.
So everyone can look back at the history
of the language evolution and understand what was proposed
and why it was proposed and why it was accepted or rejected.
And you can go and see all the proposals just by going
to the Swift-evolution repository.
And this is the process that created Swift 3,
a process driven by everyone.
And to talk more about what that has produced,
I'm going to hand it over to Chris.
Thank you, Ted.
Well, with everything else going on,
unfortunately I didn't have time
to prepare notes and slides for you.
But I printed out all the proposals
and I thought I'd read them to you now.
[Laughter] Maybe not.
So what are we trying to do here?
We said before that we want
to make the core experience of Swift great.
And that isn't just about the language.
That's also the standard library, the experience
of working with major APIs like Cocoa,
and also working with our tools.
And so we'll go through and talk about each of these in turn.
Now, our number one goal for Swift 3 is source compatibility.
And that's a big goal.
That means we want to look at what kind of code you write
in your applications and make sure
that when Swift 3 comes out,
that's the right way going forward.
And this is actually a really hard problem,
because this isn't just a matter of do we use commas
or do we use colons, that kind of stuff.
It's also about real key APIs and doing everything possible
to get Swift 3 into that shape so that we can live
with it forever and get the churn
out from underneath you over with.
Now, there's a number of different aspects of this,
one of which is that we're going to incorporate this
into the Swift-evolution proposal process
that Ted discussed before, so that any proposals that come
in after Swift 3 really think about source compatibility.
Now, I think the biggest aspect, the biggest change in Swift 3
that affects the code that we write
on a daily basis is the APIs.
And so let's dive into API naming
and just get a quick taste of what's going on.
So APIs are an essential part of how Apple thinks
about building its platform in building out the key components
that you all work with and you build
on to make great applications.
And the naming rules, and the design approaches that go
into that shape them in a really fundamental way.
And so with Swift 3, we looked
at what is the best way to write these APIs?
Do we want full verbosity?
Do we want full terseness and like the smallest code possible?
And what we found is that the thing
that really matters is clarity.
And clarity at the point of use.
And so we've really optimized
for capturing the essential important information
without encoding lots of boilerplate into APIs.
Now, let's dive into a couple of examples, and I'll show you some
of the thought process and rationale
for what this means in practice.
So here are a couple of APIs in Swift 2.
We will start with array and append contents of.
With Swift 3, this gets chopped in half.
The verb append, the operation is now the operation.
Contents of is something that describes the role
of the parameter you pass in.
Now it's an argument label that gets passed
or gets used at the call site.
This makes it a lot more clear what's happening.
Inserted index, this was already in the proper verb form,
but that index didn't add any extra information.
It was just repeating type information
that would be better to be left off.
In foundation, let's look at NSURL.
It has a file URL method or property, and just from looking
at it, it's not clear that it returns e-Bullion
and so now it starts with is making it really clear.
Another simple example is URL by pending path component,
it just drops the redundantly encoded return type
because it's not necessary.
And so there's a ton of different improvements like this
that all kind of add up together,
and there's a lot more detail and talk coming
up right after this at 10:00.
Now, let's talk about Objective-C and CAPIs
and how they work in Swift.
Because again, that's a key piece of how the APIs you work
with look and how you experience them in Swift.
We've done a number of great improvements here,
so one we call import is member.
Here's a typical core graphics API written in C.
In Swift 2 it would come in as this global function, right?
Well, this works, but this isn't the kind of API we want to work
with as Swift developers, and so we've introduced a new feature
that allows the API author to tag their API with this macro
that wraps an attribute and now gets imported
as a method providing the beautiful object-oriented APIs
that you have seen in core graphics and dispatch.
This is something you can use in your code too.
Another is generics.
We introduced lightweight generics last year with Swift 2,
and we used them to import typed collections into Swift.
But a number of frameworks
at Apple adopted lightweight generics in other ways;
for example, auto layout and core data.
With Swift 3 we are now able
to import the fully general generics right into Swift 3
as generic types, which means that a lot of cast
and redundant coding of that type information now can just
Let's talk --
Let's talk about constants.
A common pattern that we see in a lot
of Cocoa APIs are using strings as enums.
And we do this because that's in C the best way
that we could find to encode an openly extensible enum concept,
but there are a lot of disadvantages with this.
These "enums," in quotes, become these global constants
which then get imported directly into Swift as globals
and they get used with these big long names.
This is really unfortunate for a lot of reasons,
one of which is it's completely not type safe
because you can pass an arbitrary string
and it won't work.
It's also not great because it pollutes code completion
and it just doesn't feel like a very Swift API,
very good direction for Swift APIs.
With Swift 3 we solved this.
So now an API author can add a simple attribute
to their type def and now all of the different uses
of this become strongly typed in Swift.
So you'll find with NS notification names,
a commonly used one, that these now become scoped underneath
user defaults in this case, and now they get used
with proper dot syntax.
And the great thing about this is it's actually type checked.
So there are a ton
of improvements throughout the SDK adopting these
and other features that you can learn about all week long.
There are a number of great talks this week.
Let's dive into the core language.
So with these changes as context, we went back
and looked at parameter labels.
And as a quick refresher, if you had this function in Swift 2,
you'd call it and you'd use labels on two
out of the three parameters.
Why is that?
Well, the answer is that we were following the Objective-C naming
and design patterns and we wanted to be consistent
with Cocoa and the Cocoa experience in Swift.
But of course we've just radically changed how Cocoa
works in Swift, and so now we're able to bring argument labels
to all the parameters,
which makes the language a lot more consistent and predictable.
Let's talk about generics.
So the Swift generic syntax, I think,
is really beautiful and expressive.
It allows you to capture the key essence of what a function does
in a very concise and very nice way.
Unfortunately, though, when you get
into more advanced use cases,
you start adding generic constraints,
and the generic constraints are almost secondary to the behavior
of the function in this case, but they push
down the primary signature way down into the code
and it makes it a lot more difficult to read.
With Swift 3, we've extended the syntax and improved this,
so now your signature is right up front where you want
to see it and the constraints are now secondary to that.
Let's talk about unused results.
So here's a simple function.
It just adds one to a number and returns it.
With Swift 2, you wouldn't get a warning
about this code even though it's almost certainly a bug.
Maybe you forgot to assign it to a variable.
Maybe you're just calling it the completely wrong function.
Right? So with Swift 3 you get a warning by default.
This is great.
And this is also really good because it composes well
for more complicated cases as well.
So not all functions are pure like this
in the functional sense.
Some of them actually do have side effects.
We live in the real world.
And so you may be wondering, well, if I have a side effect,
maybe I'm calling this just for that side effect.
Well, that's okay, because you can assign to the underbar,
which tells the compiler and humans who have
to maintain your code that you thought about the fact
that this returned something
and you explicitly don't care about it, right?
Now, not all functions have this property.
Some functions, which are kind of the exceptions,
have a side effect as their primary behavior,
and so the return value is a secondary thing
that often you don't care about.
And so in those exceptional cases,
you can actually use an attribute to say, hey,
I know that this return value is a secondary thing,
never produce a warning if it goes unused,
which is a nice system.
So let's talk about the most exciting piece of Swift 3,
features that go away.
And you may be saying why would you do this, right?
But we really want Swift 3 to be great, right?
And Swift 3 is the sum of all of its pieces,
and many of the pieces were put
into Swift before we really knew what the language would build
into and where we wanted it to go.
And so what we did was we went back and thought about all
of the features in the language,
no matter when they were introduced,
and asked a basic question.
If this feature were not already in Swift, would we add it now?
And for some features, the answer was no,
and so we're taking them away.
And this is a great way, this is a great thing to do,
because it simplifies the language for everybody.
Now, some of these I realize may be polarizing or controversial.
The great thing about Swift-evolution is
that we debated these all as a community.
Each of these has a proposal with extensive rationale,
and if you really want to go back and read the hundreds
of emails on each of these, you can totally go back
to the mailing list archive and see what happened.
I think that pretty much every side
of every perspective was very well represented
on these issues.
So now there are a bunch of other small enhancements
to language as well, and I don't have time to go into all
of them, but we have things like generic type aliases.
We have type safe selector and key path references.
We have new build configurations, improvements
to power matching, a ton of great stuff,
and you can read them about them either in the proposals
or in the extra release notes.
Now another aspect of the core language is talking
about syntax, right?
And I think we all love, and I hope you love,
the basic syntactic structure of Swift.
I think it's one of the things that draws a lot of people in,
because it feels familiar and it works really well together.
But unfortunately, not all of the pieces
in Swift were considered with the care of the hot path
of the syntactic structures we use every day,
and so we went back,
and repainted everything a nice consistent shade
of your favorite color here, and we looked at a lot
of the weird corner cases, because those corner cases,
if they are inconsistent with the rest of the language,
it makes them even harder to use, and these are included
in the Swift because they are important.
And so we went back and standardized everything,
and we really want to get it right,
so it's right for the long time.
So that's a brief overview of the core language.
I want to dive a little bit deeper now and talk
about the type system.
First of all, what is the type system?
The type system in Swift works together with the type checker
to define how types work, and the type checker
and the compiler uses the type system
to prove your code is correct or validate that it's correct,
as well as infer things that you leave out of your code
because it's supposed to be implicit.
For example, what is a type of A?
Swift 3, we wanted to simplify the type system,
make it more consistent, and we also wanted
to define away common types of problems that people run
into that were surprising and led to bugs.
So let's talk about a few examples of this.
First is unsafe pointer, right?
So I don't know if you realize this but you can actually
in Swift 2 assign nil to an unsafe pointer.
You can test it directly for nil,
and you can actually use unsafe pointers
without having any idea whether they hold a nil or not.
This is really inconsistent with the rest of the language
and it makes unsafe pointers even more unsafe.
Well, with Swift 3, now unsafe pointers cannot be nil,
so you use optionals, just like everything else in the language.
You get to use if let to safely test them and unwrap them,
and you even get all the syntactic affordances we provide
optionals, which makes everything just work a lot
Speaking of optionals, another interesting part
of the language is implicitly unwrapped optionals.
Implicitly unwrapped optionals are a really important part
of the language, particularly when you are working
with two-phase initialization or you are calling an API
that hasn't been audited for nullability.
Now, here's an overly simplified example where I have an int,
implicitly unwrapped optional that I'm getting in,
but this applies more generally to lots
of different types of things.
Now, the basic way
that implicitly unwrapped optionals worked in Swift 2,
I think, was understandable for most people.
In the case of X, for example, well, the compiler has
to force unwrap that implicitly unwrapped optional in order
to do the addition, and so it does.
In the case of Y, well, it didn't have to,
and so if just kind of propagated it
down through the code.
Well, this propagation was surprising for a lot of reasons.
It also was surprising because more complicated cases often led
us to scratch our heads about what the code actually does.
Because you don't even know you have an implicitly unwrapped
optional in many cases.
So here, I have an int and an implicitly unwrapped optional.
Does that implicitly unwrapped optional get forced?
Do I get an array of any?
Do I get an array of optional?
What is going on?
Well, you never really know until you go
to compile your code and you get some weird compiler error,
and this is not the effect that we're going for.
So implicitly unwrapped optional is really important
as a concept, so we kept it, but we changed how it works,
to have a new, simpler model.
The model is now very local.
For any use of an implicitly unwrapped optional,
if the value can be used as an optional, it is.
That's the safe thing.
We don't want to be unwrapping values
where you don't expect it.
However, if the compiler is required to unwrap it
for type checking to succeed, it does.
So let's go through some examples again.
Here, we have X, the compiler has to unwrap it
to do the addition, and so it does.
This is the key aspect of what makes implicitly unwrapped
optionals different than strong ones.
Why? Well, here the compiler can type check the expression
as an optional, and so now instead
of propagating the implicitly unwrapped optional,
maybe deep down through your code and many different levels,
it turns into a strong optional, which allows you to think
about it and know that that's there.
This also leads to more predictable behavior
with the array, because now, of course, this can be type checked
as a strong optional, and so it does.
And if you actually want it to be unwrapped,
well, that's okay too.
You can explicitly wrap this in your code
with the exclamation mark, and now people who read it can know
about that, and your code is a lot better.
So that's my quick tour of some of the interesting things going
on with the type system.
Let's talk about the standard library.
The big news in the standard library is a whole new
collection indexing model.
And what does that mean?
Well, maybe you've worked with indexes.
There are a lot of great ways to get indexes.
The difference here is in how they move.
And previously in Swift 2, you'd call them method on the index,
like Successor, to move it forward.
In Swift 3, the model is basically the same except now
instead of the index moving itself,
the collection moves the index with itself.
And why would we do this?
Well, there's a number of great things at the Springs.
First of all, we get to simplify the standard library.
A bunch of types just go away, which is great.
Even better, common kinds of problems get defined away.
You can now have an inclusive range all the way
up to the maximum element, which previously would trigger a trap
which nobody expected.
We also think this is going to bring better performance,
because we can get rid of our tandem releases
with many common collections.
So we are pretty excited about this.
Let's talk about numerics.
We have a new floating point protocol or family of protocols
which help define operations to allow you
to write generic algorithms across a broad range
of FloatingPoint types.
Even better, if you are a numerical analysis type person
and you understand IEEE FloatingPoint, which is not me
and not most people, but it has a lot
of great low level operations, like getting the number of ULPS
out of the whatever, some really important smart stuff here.
[Laughter] So I don't really understand all that stuff.
I think it's really important, though,
and people who do really value it.
I do understand things like Pi, because everybody loves Pi.
And in Swift 2 we always got stuck using MPi,
and it really irritated me
because it was always the wrong type, and you also had
to cast it, and it always led to huge frustration.
Well, now, despite all that IEEE stuff, you know,
in addition to all that IEEE stuff, we even get great things
like Pi on all the FloatingPoint types.
And Swift often has types available.
And the other great thing about this is
that if you have typed context, for example,
here we're returning a CGFloat, instead of doing a cast,
you can use CGFloat.Pi, but even better you can allow the
compiler to infer that completely for you.
It leads to a really nice result.
So as with the language, there's a ton
of great improvements throughout the standard library.
Some of these can really effect
and really improve the code you write in Swift,
so I highly recommend sticking around for the other Swift talks
which will dive into more information.
So this was a quick tour of the language, the standard library,
how Cocoa works in Swift, but the next big piece is how Swift
and the tools work together.
So to talk about that, I'd like to invite up Ewa Matejska.
Thank you, Chris.
Good morning, everybody.
Let's talk about Tools, and what better place to start
than what the tools can do for your performance.
As you can see, we've been really busy this year,
but let's talk about a couple of these.
We revamped the dictionary implementation,
and we also really focused
on optimizing the string hashing algorithms for ASCII strings,
and we see some really nice improvements
in our micro benchmarks for dictionaries
that use strings since last year.
We also added stack promotion
for class instances array literals, where we promote
from the heap, which is really expensive, to the stack,
and we see some really nice improvements
when our tests take advantage of that.
Also, as I already described, we really focused
on our string hashing algorithms, and we see this
in a dramatic way in our tests that compared the prefixes
and suffixes of strings, like we get 86 times improvement.
Next, I want to talk to you about whole module optimization.
This is a feature we introduced last year,
but I want to just remind you a little bit about what it is.
When you look at this diagram,
you can see a really parallel compilation flow,
one file in, one file out.
With whole module optimization, we expand the scope
of compilation from one file to multiple files.
And this is really great because the compiler has a lot more
information to write new, innovative optimizations
and to make your code run faster.
So we think this has so much promise
from our internal benchmarking, that this year we are turning it
on by default for all new projects.
And existing projects will get a modernization suggestion and,
as it suggests, we think you should modernize and adopt it.
There's a big caveat, which is compilation time.
As you look in this diagram, you probably noticed
that the compiler is a bit of a bottleneck.
And as you would expect, your compilation time increases.
To offset this cost, we have made the compiler a lot smarter
and it's caching as much as it can
to avoid reoptimization and recompilation.
So the result of all this is
that although the first time you compile, it will be --
it will take a longer time, follow-up,
incremental compilations should be faster.
Moving on to code size, this is an area that got --
we did a lot of work in since Swift 2.2,
and we have some nice results.
DemoBots is a sample app that you can download from Developer
at Apple.com, and it saw a decrease
in its application binary size of almost 25 percent
since Swift 2.2, so that's some really nice ones here.
Well, that's all I have to say about performance,
but there's lots more to talk about in Xcode.
So my favorite feature in Xcode this year is the improved
navigation of Swift code because it really makes a difference
every day in development.
Let's take a look at an example.
So here's an example where we create an array of integers
and then just go Sort.
What do you think happens when you right click on Sort
and jump to a declaration?
In Xcode 7.1, you take
in a synthesized header that looks like this.
Like what is this?
It's an extension to mutable collection type,
the sort here return self that generated that element,
and the only reference to array is in a comment.
So it doesn't make very much sense and it's not very logical.
So in Xcode 8, we're doing a lot better,
and now you see there's an extension to an array
like you would expect and sorted, because sort was renamed
to sorted in Xcode 8, now returns an array of elements.
So this really improves how you can navigate the code
in Xcode and its readability.
It's much more logical.
Also, in the standard library,
we added groupings by logical areas.
For example, array is grouped under collection.
And speaking of the standard library, we have all kinds
of new documentation for you.
And again, the protocols are locked into the APIs,
so you can logically navigate like you would
in the synthesized interfaces.
I think you're going to really love this part.
Yeah. So how many people have Swift 2.2 code?
Probably lots of people.
So, of course, we have the migrator for you like always,
but this year you get to choose.
You get to choose Swift 2.3 or Swift 3.
If you're not quite ready to jump to Swift 3,
Swift 2.3 is just Swift 2.2 that works with the new SDKs, okay,
and we will be accepting submissions to the app store,
both with Swift 3 and 2.3, but you should be aware
that there are some very key features in Xcode that depend
on Swift 3, like Playgrounds and Documentation
and the new features as well, like Thread Sanitizer.
Swift 2.3 is a really an interim solution
to allow you the flexibility
to schedule time to update to Swift 3.
So please schedule it today.
Yeah. If you are using Swift 2.3,
I have a little tip for you.
Here is a sample.
It's a little code snippet from the lister sample that's in 2.2.
And when you run the Swift migrator to 2.3,
it will suggest you add an exclamation mark after frame,
because the core graphics API have improved
with additional ability editing.
Now this code compiles both with Swift 2.2 and Swift 2.3,
but if you have a little more complicated scenario,
you could conditionally compile your code
with a pound FL statement here.
So that's just a little tip.
And when you are ready, when you are ready to upgrade to Swift 3,
the migrator is there for you.
Just go to Edit, Convert to Current Swift Syntax,
and you are taken through the migration experience again.
So it's easy.
Convert to Swift 3 and schedule it today.
So that's all I have to say about tools.
And just to recap, recap, Chris talked
about how Swift 3 really focuses on nailing
down the fundamentals.
And we're doing all this in the open on Swift.org,
as Ted described, and you can just go there and get involved
in the evolution process.
And you can see we've got awesome Xcode integration
So there's lots more information this week.
There is just the beginning.
And we have lots of sessions throughout the week.
I want to highlight one,
which is the Swift API Design Guidelines.
It's in this room right after this session.
And have an awesome week with us.
Looking for something specific? Enter a topic above and jump straight to the good stuff.
An error occurred when submitting your query. Please check your Internet connection and try again.