| < How and when did Swift get its name? | Were there changes between the first Swift beta and release? > |
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.
SPONSORED AppSweep by Guardsquare helps developers automate the mobile app security testing process with fast, free scans. By using AppSweep’s actionable recommendations, developers can improve the security posture of their apps in accordance with security standards like OWASP.
Sponsor Hacking with Swift and reach the world's largest Swift community!
