FREE TRIAL: Accelerate your app development career with Hacking with Swift+! >>

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

Hacking with Swift is sponsored by Essential Developer

SPONSORED From August 2nd to 8th you can join a FREE crash course for mid/senior iOS devs who want to achieve an expert level of technical and practical skills – it’s the fast track to being a complete senior developer!

Save your spot now

Sponsor Hacking with Swift and reach the world's largest Swift community!

BUY OUR BOOKS
Buy Pro Swift 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 (Vapor Edition) 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 Server-Side Swift (Kitura Edition) 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.