
Swift 3.0 Released - olenhad
https://swift.org/blog/swift-3-0-released/
======
tveita
Does this release include a cross-platform Foundations library?

[https://github.com/apple/swift-corelibs-
foundation/blob/mast...](https://github.com/apple/swift-corelibs-
foundation/blob/master/README.md) says they intend it to be part of Swift 3.0,
but [https://github.com/apple/swift-corelibs-
foundation/blob/mast...](https://github.com/apple/swift-corelibs-
foundation/blob/master/Docs/Status.md) still lists a lot of classes as
"Incomplete" or "Unimplemented"

------
thomasahle
Wow, they've basically renamed the entire Standard Library, see the changeset:
[https://github.com/apple/swift-
evolution/blob/master/proposa...](https://github.com/apple/swift-
evolution/blob/master/proposals/0006-apply-api-guidelines-to-the-standard-
library.md)

Not that I mind though. This kind of thing should be easy to auto refactor.

~~~
oblio
This usually madness for production projects, unless you're Apple (or
Microsoft in the 90s).

But I wish Python 3 did the same with its libraries.

~~~
masklinn
Python 3 did implement pretty significant library changes, though mostly
organisational (namespace restructuring, merging of C accelerator modules,
renamings, removal of deprecated modules, …):
[https://www.python.org/dev/peps/pep-3108/](https://www.python.org/dev/peps/pep-3108/)

------
hellofunk
One thing I never understood about Swift and that I don't think is addressed
in Swift 3 is the widespread inconsistency with simple 'if' statements. There
are at least three incompatible ways to think about 'if' syntax in Swift:

if foo == 1 && bar ==2 //normal, from other languages

if let somevar = foo, let anothervar = bar //note, must use a comma rather
than &&

if case .someEnum = foobar //cannot use == !

That latter would be much easier to think about like foobar == .someEnum but
it gets mucked up.

I don't understand why these can't be streamlined into something like this:

if let a = b && let d == f && foobar == .someEnum //you can't do any of this

Instead, you have to use "where" and commas rather than && in some places, the
whole thing is a much greater cognitive overload than it should be for such a
fundamental task in any language.

~~~
masklinn
Your cases 2 and 3 are _pattern matches_. It's perfectly fine to use regular
equality with optionals (case 2) or enums (case 3), but in that case you're
not _matching a pattern_ you're comparing _two specific values_ , and you need
the types to be equatable[0] (enums aren't by default, though optionals are if
they contain an equatable value).

* you can write "foobar == .someEnum" if you've defined "==" for your enum type (in Rust that's a deriving(Eq) away, sadly Swift doesn't seem to have deriving):
    
    
        // requires conforming to Equatable, and implementing
        // requires func ==(a: Foo, b: Foo) -> Bool somewhere
        // if the enum has associated data[1]
        let v = Foo.Bar;
        if v == .Bar {
            print("ok")
        }
    

you can also do that with optionals by default:

    
    
        let w = Optional.some(3)
        if w == .some(4) {
            print("ok")
        }
    

* `let a = b && thing` doesn't make sense because `let a = b` is not a boolean value it's a pattern match. That's why you have a separate _guard_ (the where) and have to write `let a = b where thing`, this is what happens in pretty much every language with pattern-matching (though syntax may vary)

* `let d == f` makes no sense whatsoever, though as previously noted `f == .some(d)` works

* you can compose `if case` and `if let` in, since both are pattern matches, `if case .Bar = v, let b = w` works fine

If you're getting lost with that, use the regular `if` for boolean stuff, and
a full `switch` for all patterns. There, I fixed it.

That aside, I do agree Swift's syntax is convoluted and complex. Part of that
comes from `if let` being special-cased to optionals, which is convenient when
you're working specifically with optionals but means a separate syntax for
other enums.

On the other hand, most languages with pattern-matching don't provided a
"conditional-ish" version, Haskell's `if` works solely on booleans, if you
want to work with patterns you have to break out the full `case`. Rust lifted
`if let` from Swift (with different semantics) because it was such a neat
idea.

[0] [http://www.andrewcbancroft.com/2015/07/01/every-swift-
value-...](http://www.andrewcbancroft.com/2015/07/01/every-swift-value-type-
should-be-equatable/)

[1] for trivial enums (no associated data, though they can have a rawValue),
you can just `enum Foo: Equatable` and it'll get a proper implementation; for
the rest you have to implement == yourself:
[http://www.jessesquires.com/swift-enumerations-and-
equatable...](http://www.jessesquires.com/swift-enumerations-and-equatable/)

~~~
hellofunk
> you can write "foobar == .someEnum" if you've defined "==" for your enum
> type

Why wouldn't enums be equatable by default? Why rely on a user implementation
of ==? Enums, even with associated data, are rather obvious values, aren't
they?

~~~
masklinn
> Enums, even with associated data, are rather obvious values, aren't they?

Associated data can be completely arbitrary (and thus possibly not equatable),
I expect the designers would rather people use pattern matching instead of the
more error-prone boolean constructs, and likely they don't want to add
"unnecessary" capabilities so if the developer don't need equatable enums
there's no reason to make them and developers can ask for it when they need
it.

Rust makes the same choice, so does haskell, though in both enum/data equality
is just a derive/deriving away.

------
nicky0
I look forward to using Swift in a couple of years when it is all stable. It
looks great. Thanks to those of you using it now and contributing to its
improvement.

~~~
rimantas
Swift 4 is supposed to be source compatible with Swift 3, so no need to wait.

~~~
nicky0
I don't want to have to ship apps containing the entire runtime. I'm waiting
for the stable ABI.

As well, I'm happy to let the keen early-adopters be the guinea pigs. Xcode 8
only came out today. If you have production apps, it's madness to upgrade on
day one. I'll wait a few weeks/months for the remaining bugs to shake out.

Don't get me wrong I'm very pro-Swift. But I'm also mindful of my time and
sanity. Switching to a new language sure sounds fun, but not exactly
productive (in the short term). When I do switch, I want everything to be rock
solid, stable, all the tools, docs and everything.

But I have created a couple of toy projects in Swift, and I'm very excited to
start using it properly in a year or two.

~~~
untog
I've only recently gotten into iOS development and the state of XCode amazes
me. It's awful. Frequent crashes, disappearing tests, syntax highlight
shutting down... it really makes me wish there were an alternative.

~~~
armadsen
A lot of this is worse for Swift than it is for Objective-C. Still, I do find
it weird that such a mature product (roots going back decades, really) is
still so shaky in fundamental areas. In many ways it has actually regressed
since e.g. version 3.

~~~
72deluxe
I found versions 5 and 6 really buggy. 7 got better but I am waiting a while
before going to 8. It is just too risky to upgrade so soon, given its years of
buggy releases. It's poor.

------
WoodenChair
What is the possibility of having Swift added upstream to Debian or Ubuntu so
that I can just apt-get install it on those platforms?

------
mark_l_watson
"Official binaries for Ubuntu 14.04 and Ubuntu 15.10..."

I am surprised they don't support the latest Ubuntu with official binaries?

~~~
knocte
+1, they should consider 16.04.1 which is also an LTS, not 15.10.

------
dep_b
Swift 3.0 is really nice but I backtracked out of Xcode 8.0 for now. I am used
to Xcode but this one still vomits Apple internal debug messages into the
console, that's really too rough for me. I'll wait for the .01 or the .1
before upgrading all my projects.

Funny thing is I downloaded one of the first if not the first beta of Xcode 8
and it already migrated my projects flawlessly (where possible). It's all the
other stuff that's broken.

~~~
kybernetyk
I hope I can get used to work without the Polychromatic plugin[1]. Or that the
dev somehow can get around the new plugin sandbox in Xcode.

Haven't tested it yet with Xcode 8 but I fear it won't work.

[1] -
[https://github.com/kolinkrewinkel/Polychromatic](https://github.com/kolinkrewinkel/Polychromatic)

~~~
LeoNatan25
Isn't the sandbox only enabled if System Integrity Protection is enabled?
Disable that and the plugins should work, if they are updated for Xcode 8.

[Update] Hmm, seems so. See this:
[https://github.com/inket/update_xcode_plugins](https://github.com/inket/update_xcode_plugins)

------
justsaysmthng
If you're thinking of updating to Xcode 8, hoping that your project will 'just
build', don't get your hopes too high.

I've already spent all day fixing, updating, searching around for all kinds of
errors that the build system throws at me. It also required me to update the
project dependencies to their latest versions which support swift 3/xcode 8.
Some dependencies (like SwiftBond 5) have changed a lot and now my project has
hundreds of syntax errors due to renamed methods, not that hard to fix, but
not sure if they'll still run the same...

So this is a major upgrade to your project - do it when you have spare time to
waste.

In the meantime, I'm thinking of reverting to Xcode 7.3 and running the two
versions side by side... Is that possible ?

~~~
mrsteveman1
> In the meantime, I'm thinking of reverting to Xcode 7.3 and running the two
> versions side by side... Is that possible ?

I think you're probably better off just keeping Xcode 8 by itself, but use
Swift 2.3 for projects if you need to. There are very very few differences
between 2.2 and 2.3, converting existing code over is much faster than 2.2 ->
3.0.

~~~
justsaysmthng
Tried that, but it seems the build setting now needs an explicit SWIFT_VERSION
configured .. And carthage dependencies don't have that so the build fails.

Basically, I couldn't get my carthage dependencies to compile with Swift 2.3,
so I went the Swift3 route, which now, after 10 hours wasted, was such a bad
idea!

Appstore was bugging me to update Xcode so I caved in and now I'm stuck with a
project that doesn't build and the deadline approaching fast. Such a useless
waste of time.

~~~
mminer
To placate Carthage dependencies that complain about a missing SWIFT_VERSION
configuration, try setting the TOOLCHAINS environment variable.

    
    
      TOOLCHAINS=com.apple.dt.toolchain.Swift_2_3 carthage bootstrap

~~~
justsaysmthng
This is the thing I've been looking for !

Thank you for the 63 characters of wisdom, my project now builds !

------
valarauca1
So is 3.0 when Swift is finally gonna settle into stability? Or are they gonna
wait until 4.0 to stop breaking backwards compatibility?

~~~
K0nserv
AFAIK Swift is going to be source compatible going forward(don't quote me on
that), but ABI stability is not going to be there until 4.0.

EDIT: See steveklabnik's comment
[https://news.ycombinator.com/item?id=12495200](https://news.ycombinator.com/item?id=12495200)

~~~
steveklabnik
I have a link that says exactly this posted downthread.

------
sswezey
I really wish Swift releases were not pinned to Apple releases. Swift 3
introduced several regressions and instead of prioritizing some serious
regressions, they focused on swift evolution proposals. For example, one
accepted proposal renamed the common array _flatten_ method to _joined_
because it aligned one use case. Granted this is low hanging fruit, but a
whole bunch of low hanging fruit takes time away from serious bugs and
enhancements.

If Swift really wants to become successful, they need to work on bigger
picture things like fixing breaking regressions, planning full reflection,
built-in async instead of bikeshedding about array methods. I understand they
want a non-breaking API from 3.0, but everyone isn't always going to be happy;
and changing small functions for the vocal minority is not the correct path
forward.

A list of 3.0 regressions:
[https://bugs.swift.org/browse/SR-2603?jql=labels%20%3D%203.0...](https://bugs.swift.org/browse/SR-2603?jql=labels%20%3D%203.0Regression)
Flatten rename proposal: [https://github.com/apple/swift-
evolution/blob/master/proposa...](https://github.com/apple/swift-
evolution/blob/master/proposals/0133-rename-flatten-to-joined.md)

~~~
timjver
The renaming of flatten to joined was a last-minute proposal, and it wasn't
even implemented by someone of Swift's core team. I don't think it distracted
the team much at all.

Also, breaking changes such as this one were a lot easier to make in Swift 3
than in a later version.

~~~
st3v3r
If they're still making breaking changes like this, then why have they
declared version 1? They should still be on version 0.x

~~~
SamReidHughes
Why?

------
insulanian
> It is not source-compatible with Swift 2.2 and 2.3.

This created havoc in Python. Hopefully it won't happen here.

~~~
jonathanstrange
It makes a lot of sense, though. Like many new languages Swift was invented
hastily and without much care with the main goal of locking in developers and
preventing cross-platform development. If Apple made major releases backwards-
compatible, this would invariably turn the language into a big mess in the
long run.

This way, the language can evolve into a fine language with many features from
Algol-68 and the usual semi-popular C-ish syntax, and Apple can continue to
ensure that developers have to maintain a separate codebase for their "apps"
that is useless anywhere else.

~~~
jasode
_> Swift was invented hastily and without much care_

Swift was started in July 2010 by Chris Lattner[1] and it was publicly
announced by Apple in June 2014 (and the 1.0 release was September 2014).
Spending 4 years on it and including other programming language experts to
contribute to it doesn't seem like a reckless and thoughtless release. What it
shows is that even if a group spends _years_ on it, they will still get a lot
of things wrong. Same for C# that was (formally) started in January 1999 and
not publicly released until December 2002. Even though that language also had
4 years of gestation by smart people, they still got generics and a bunch of
other things wrong (e.g. terrible name of "destructors" for the concept of
finalizers.)

I didn't realize that programmers thought Swift was created in a hurry like
Brendan Eich's "10 days" to design Livescript/Javascript for Netscape
Navigator[2]

[1][http://www.nondot.org/sabre/](http://www.nondot.org/sabre/)

[2][https://www.quora.com/In-which-10-days-of-May-did-Brendan-
Ei...](https://www.quora.com/In-which-10-days-of-May-did-Brendan-Eich-write-
JavaScript-Mocha-in-1995)

~~~
cageface
I like Swift but it really was released too early. There were fundamental
problems with the tooling for a long long time after the first release and
there has been a lot of churn in the syntax even after the tooling started to
settle down.

Designing a language like Swift is hard and it's not reasonable to expect them
to get everything right on the first try but I do think it would have
benefitted from a lot more dogfooding before they started pushing it on
developers.

~~~
jasode
_> There were fundamental problems with the tooling for a long long time after
the first release _

I was speaking of the _language syntax and specification_ separately from the
"tooling." Virtually every language has terrible tooling when it's first
released. (e.g. Golang doesn't have a real debugger, Rust build chain on
Windows is suboptimal, etc). Yes, Apple's Xcode and Playgrounds were extremely
buggy with Swift. Given decades of computing history, it's unfortunate that
bugs are to be _expected_ of new programming languages.

There are very few languages that emphasize tooling from the very start.
Examples that come to mind would be 4GL type languages (SAP ABAP,
Powerbuilder) because those proprietary languages often force you to work
inside of their GUI editors. Smalltalk might be another example.

------
awzurn
Can't wait for the day when they're done deciding to only make major releases
every year, and actually settle on a common syntax and platform for the
language, will be great not having to worry about my source code blowing up...

... then again, seeing some actual refactor support in Xcode would be pretty
great too, but you can't wish for too much at once.

~~~
knocte
It's a matter of taste.

As for me, that I tinkle more with .NET, I see their (Swift's) grass greener
in the fact that they are not afraid of making breaking changes if they truly
benefit the platform, something which I don't see MS doing anytime soon.

~~~
ZenoArrow
> " in the fact that they are not afraid of making breaking changes if they
> truly benefit the platform, something which I don't see MS doing anytime
> soon."

MS have made plenty of big changes recently, .NET Core being a prime example.

~~~
knocte
I was talking about languages.

------
leshow
Every time I see swift, it's crazy how much they've 'borrowed' from rust. The
language looks almost identical

~~~
Manishearth
I don't think swift has borrowed much from Rust.

Rather, both are borrowing from older functional languages. These features are
relatively new for procedural languages so it seems like Swift borrowed from
Rust, but both have borrowed these features from other languages.

Rust did borrow `if let` from Swift (might have existed in other languages,
but Swift is where the idea came from). I'm sure there are a few features
swift has borrowed from Rust, but not many.

And it's not a bad thing to borrow! (As a Rustacean) I'm happy that Swift is
similar to Rust. One of the problems with Rust is the learning curve for folks
coming from other languages. With more languages similar to Rust, this is less
of an issue. Swift in particular is set up to be used a lot since Apple is
pushing it in its ecosystem, which is great.

------
overcast
Sounds like an ideal time to dive into Swift, and start building something
new.

------
prit91
Most of the API's are changed. Will need to migrate the code base from swift
2.3 to swift 3. Tedious work. But what I liked about the swift 3 API change
was the swifitification of the GCD API. I liked it

------
skybrian
Interesting that they dropped curried functions. Why do functional programmers
seem to like it so much and mainstream programmers don't care?

~~~
jeffdavis
I've always found it annoying because it only works if you want to bind the
first argument. If you want to bind the second, you have to do something else.

Disclaimer: not an expert on this subject.

------
antiquark
But how can anybody take a language seriously if it doesn't have ++ and --
operators?

------
andrewvijay
BREAKING again? Demotivating a lot.

~~~
TazeTSchnitzel
Swift is a young language. That it breaks some things now means we won't be
stuck with its early mistakes forever in ten years.

~~~
andrewvijay
Yes. But everyone cares about their code base which they have today not after
what they are going to do in 10yrs. An asteroid could wipe us all tomorrow. So
I'm definitely worried about reworking stuff that I already wrote.

------
unknowingone
How can I get Swift 3.0 going on my Mac if I don't want to upgrade from
Mavericks?

~~~
nicky0
With great difficulty.

~~~
unknowingone
I only use the command line and have no use for Xcode. With LLVM or GCC I can
install as many versions as I want side by side - not the case for Swift.
Lame.

------
jinmingjian
congrats!

------
fit2rule
Holding off on learning much more Swift for now, until things stabilize and
stuff stops breaking. Its not much fun to go back to learn some Swift only to
discover things have changed since last time ..

~~~
sgt
No need to hold off - now is actually the time to start learning Swift, as
it's taking off. If you've written existing code, it will take you minor
effort to translate the code (in most cases) and you can also use the code
migrator tool.

~~~
fit2rule
Yeah, I guess with 3.0 it is time to dust off the ol' ~/hak/swift/ dir and see
what it'll take to bring previous hacks forward ..

