Dear Erica: “What do you think is going to be the biggest/best Swift 3 change for people who haven’t been following the process? I’m feeling a little underwhelmed, to be honest.  Compared to the Swift 1 -> 2 changes (aka protocol extensions) it feels like there are big changes, but not ones that change how you approach designing a program…“

I’m not entirely sure that “no new paradigm shifts” are a bad thing. As a language, Swift pretty much knows what it is. It hasn’t quite reached fully cooked (incomplete generics in Swift 3 are a really good indicator that the language still needs more time in the oven) but it’s settled on what kind of language it is. There’s a clear Swift philosophy that’s driving the effort.

Swiftory

Swiftory goes something like this:

Swift 1 set the baseline: type safe, fast, modern. It showed what Swift could be. We got optionals, smart value types, and a lot of great features that started the hard sell. It’s where a lot of Objective C programmers sat up and said “Oh, look at that. There’s something there worth investigating.”

Swift 2 revolutionized itself with protocol oriented programming and lots of cool new feature like reengineered error handling. It showed what Swift should be. Suddenly, Swift wasn’t just making sense, it was creating new paradigms for the Apple community and, after open sourcing, making inroads towards new platforms.

Swift 3 is the”clean house”, “break everything” release. Think of this as necessary language trauma to ensure the language fundamentals are sound and consistent going forward release. It might not be the funnest release (when put on the spot, the best I could come up with for pure “joy” features was Lily Ballard’s sequence/take/drop functions) but it’s one that’s creating a massively cleaner language.

Swift 4 should hopefully be full of additive glory. We should see completed generics, concurrency, and more: features that are fun, provocative, and powerful. Swift 4 gets to be inspired by other languages and will incorporate several years of public use and feedback. Swift 4 should be the release that “doesn’t break nearly as much stuff”, which if you think about it, isn’t exactly how public relations should try to sell it. (It’s also probably where the Swift Package Manager should hit its “Swift 2” glory phase.)

Denial, Anger, Bargaining, and Acceptance

There’s plenty in Swift 2 -> 3 that’s going to freak people out. We’re seeing the death of beloved vestigial constructs. Swift’s renaming everything in what are frankly weird ways (“sorting”, “unioning”, etc — and no, I cannot guarantee that the API directives weren’t settled on without the use of hallucinogenics when you compare these to “sortInPlace” and “unionInPlace”). There’s prefix stripping on familiar names and defaulting arguments changing the way signatures look, and so forth.

A lot of this feels like a language enema. It’s not really a transition you seek out for fun but it can get your development moving properly again afterwards. (“Swift 3: The healthy fiber update!”)

Sure, it’s hard to get super excited about language changes like “move inout keyword to decorate type instead of label” but these are necessary housekeeping if the language is going to keep its promise of excellence and deliver on the next phase of its roadmap.

If there’s anything missing in my summary about the roadmap to Swift 3, it’s this: Swift is a really great language to work in. And Swift 3 is a better language to work in than Swift 2 was.

I may laugh at some naming choices and worry about unfamiliar Cocoa calls but all in all, Swift is the language I’d like to be writing code in for the next few years. And I think after Swift 3 drops, a large part of the Apple community (and beyond!) will agree.

You’ll find a list of adopted and implemented Swift 3 proposals in the main Github repo README. They may look a little boring but they’re going to shake things up. In a high-fiber vitamin laden smoothie kind of way.