Swift 3.0 Released (opens in new tab)

I don't mind either. And I have a commercial Mac application written 98% in Swift to maintain.

Now the risks were known when we green fielded the project. It was certain that Swift syntax and the frameworks would change in the future. But the time we saved in development makes up many times for the maintenance burden now.

Luckily refactoring strongly static typed code is not that of a fiasco :)

Yes, not really a problem in that case. But let's not forget that this release also contains nearly 50 other source breaking swift-evolution proposals (full changelog here: https://github.com/apple/swift/blob/master/CHANGELOG.md).

But one of the things I like about how the language is begin developed is that everyone involved is aware that having the language in a constant state of flux is painful, and try to provide useful warning messages (or wizards if you use XCode) for those that will need to update their code to a newer release sooner or later.

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.

I don't agree - case 2 and 3 aren't returning boolean values, they are matching on a pattern. Perhaps using the if keyword was a mistake there, but the commas and equal sign aren't. I think using the && and == syntax is strange when you aren't comparing 2 boolean values.

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-...

[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...

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

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

15.10 was the latest when Swift was originally open sourced. My guess is they were a little busy over the summer to update to 16.04. :-)

there's a settings flag you can add to stop those internal debug messages, which I believe started in the XCode 8 Beta. It is pretty annoying that this not clearly mentioned or toggle-able in the UI

https://twitter.com/rustyshelf/status/775505191160328194

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

> 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.

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

Yes, at least that seems like the plan. Take the pain now in order to get it stable.

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.

The only thing better than bikeshedding about minor language features is bikeshedding about the language evolution process...

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

There are big differences though:

* Python had 15 years of source-compatibility before the switch, Swift has 1 year and a history of source-incompatibility (Swift 2 was not source-compatible with Swift 1)

* Python had a fair amount of semantic-incompatibility

* Python doesn't have a (heavy) compiler backing it up making source and semantic incompatibilities runtime issues your program bashes its face in rather than cascading compilation failures

As per the blog [0], you can expect a lot to break.

  Swift 3 is a source-breaking release, largely due to the
  changes in SE-0005 and SE-0006. These changes not only impact
  the names of the Standard Library APIs, but also completely
  change how Objective-C APIs (particularly from Cocoa) import
  into Swift. Many of the changes are largely mechanical, but
  they can be numerous in a typical Swift project.

  To help with moving to Swift 3, Xcode 8.0 contains a code
  migrator that can automatically handle many of the need source
  changes. There is also a migration guide available to guide you
  through many of the changes — especially through the ones that
  are less mechanical and require more direct scrutiny.

[0] https://swift.org/blog/swift-3-0-released/

Until now Swift has not promised source compatibility so the developers should be ready to rewrite their code for new versions. I would not be surprised if Swift 2.3 support were dropped in the next version of XCode completely.

The migration tools are quite good though so going from 2.2 to 3.0 directly should not be much of a problem.

I think that in Python the problem was/is that the 2.x was already a massively used and mature language when the 3 came out.

It has also created havoc in the Swift world. Suddenly all existing Swift code is broken. The migration tool is supposed to take care of most of this for you but my experience has been that it misses a lot of things and upgrading requires many manual fixes. Of course every Swift library in existence also needs to be updated so your changes of a smooth migration right now are slim.

Apple has the resources to push this through and developers don't really have much choice so I don't expect this to become another Python 3 fiasco but this really should be the last time Apple breaks so much code just to clean up the syntax a bit.

Almost every version of Swift until now has had source-breaking changes. We're used to fixing things every 6 months or so.

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.

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.

AppCode delivers fantastic refactoring support. $20 per month is not that expensive, and licenses for open source development are free.

A major release doesn't necessarily have any breaking changes. Swift 4 will contain some breaking changes for sure, but Swift 5 might not.

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.

Actually what both 'borrowed' from ML, specifically OCaml.

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.

We should all be so lucky that some other languages are willing to break backwards compatibility. Even C++ gurus like Scott Myers advocate that language finally breaking source compatibility [0]. Often, breaking compatibility is the only way to make a language better.

[0] http://scottmeyers.blogspot.nl/2015/11/breaking-all-eggs-in-...

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.

Demotivating only if you've ignored the many public discussions about how this was going to be the case.

With great difficulty.

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.