WWDC23 SALE: Save 50% on all my Swift books and bundles! >>

How did you decide what went into Swift at launch?

Recorded – watch the full episode on YouTube.

How did you decide what language features would go into Swift 1 and what would be pushed back to Swift 2 or later?‌

Chris Lattner: Swift 1 ended up being a time-driven release. Basically a decision was made in the spring, roughly, that it made sense to launch Swift. As part of that launch, we specifically decided that we would be willing to change the language after we launched it. We were not going for the platonic ideal that we could live with forever. We thought that was impractical. So instead we decided that we could launch something, be transparent with the community and say, we plan to change this. That enabled a time-driven release.

Different features fall into different categories. Error handling with try and catch was always planned. And I believe that if you go look at the history in version control, you'll see that the design document for that predated Swift 2 by quite a long time.

"We were not going for the platonic ideal that we could live with forever. We thought that was impractical. So instead we decided that we could launch something, be transparent with the community and say, we plan to change this."

Others, like defer, well, actually defer was part of error handling, others, like guard, really came about as a consequence of community feedback. One of the things that Swift 1.0 had was it didn't have the ability to put multiple conditions in an if. You'll normally write if let something, and then if you want to write let something else or some Boolean condition, now you can put commas in there to separate those out. In Swift 1.0, you couldn't do that. And so you got this very deeply nested code that people affectionately call the Pyramid of Doom.

That was very much a thing. The duel of that is what guard covers. And guard, if you end up having a huge number of conditions to check this side of the other thing, it ends up with the body of your code deeply nested under a pile of these conditions. And so guard came about as a response to how we improve the ergonomics of the language, how do we make it better for people to use, and how do we make the code more readable? And that came right from a user experience and from people complaining on blogs, basically, which is fantastic. It's amazing to get that feedback.

One of the things that I love about folks who take the time to blog is that often they spend a lot of time framing the argument, and so by explaining the issue and explaining both sides and explaining what happens, that really helps make a persuasive argument versus just the whining that you'll see on, for example, Twitter. And so I always appreciate that.

This transcript was recorded as part of Swiftly Speaking. You can watch the full original episode on YouTube, or subscribe to the audio version on Apple Podcasts.

Listen on Apple Podcasts

Save 50% in my WWDC23 sale.

SAVE 50% To celebrate WWDC23, all our books and bundles are half price, so you can take your Swift knowledge further without spending big! Get the Swift Power Pack to build your iOS career faster, get the Swift Platform Pack to builds apps for macOS, watchOS, and beyond, or get the Swift Plus Pack to learn advanced design patterns, testing skills, and more.

Save 50% on all our books and bundles!

BUY OUR BOOKS
Buy Pro Swift Buy Pro SwiftUI Buy Swift Design Patterns Buy Testing Swift Buy Hacking with iOS Buy Swift Coding Challenges Buy Swift on Sundays Volume One Buy Server-Side Swift Buy Advanced iOS Volume One Buy Advanced iOS Volume Two Buy Advanced iOS Volume Three Buy Hacking with watchOS Buy Hacking with tvOS Buy Hacking with macOS Buy Dive Into SpriteKit Buy Swift in Sixty Seconds Buy Objective-C for Swift Developers Buy Beyond Code

Was this page useful? Let us know!

 
Unknown user

You are not logged in

Log in or create account
 

Link copied to your pasteboard.