Transcript
[ Music ]
>> Good morning.
[ Applause ]
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
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.
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.
All right?
Swift is really intended to
be a powerful tool in the hand
of developers, and in their
hands they can do really
amazing things.
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,
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,
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,
management experience.
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 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 volunteered.
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
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
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
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
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
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.
Doesn't matter.
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.
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,
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,
And to talk more about
what that has produced,
I'm going to hand
it over to Chris.
[ Applause ]
>> 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.
Sound good?
[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
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?
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.
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 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
go away.
Let's talk --
[ Applause ]
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
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.
[ Applause ]
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.
[ Applause ]
Let's talk about generics.
So the Swift generic
syntax, I think,
is really beautiful
and expressive.
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.
[ Applause ]
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.
It's safe.
This is great.
And this is also really good
because it composes well
for more complicated
cases as 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,
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.
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
more predictably.
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.
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,
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
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.
Maybe not.
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
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
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.
[ Applause ]
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.
Ewa?
[ Applause ]
>> 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
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,
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
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,
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,
And again, the protocols
are locked into the APIs,
so you can logically
navigate like you would
in the synthesized interfaces.
[ Applause ]
Thank you.
[ Applause ]
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.
[ Applause ]
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
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
as well.
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.
It's in this room right
after this session.
And have an awesome
week with us.
Thank you.
[ Applause ]