How did you start creating Swift?

Recorded June 18th 2020 – watch the full episode on YouTube.

In the early days of Swift, how quickly did the language fundamentals come together, and what were the language fundamentals in those early days?

Chris Lattner: That's a great question. I think that a lot of the basic ideas the language started with really have seen their way through and they've gotten refined and improved for sure, but a lot of the ideas were making it so that the language could be extensible.

I've worked with a number of languages, including C++. It allows you to define custom types so you can define a complex number for example, but it has a whole bunch of really weird things that are thrown into the language. Why are integers a primitive built-in thing? Why are there all these weird rules that are hacked into the language? You have dissonance between the library extensible parts of the language and the language core pieces.

"If you build primitive first-class things right into the language, then library developers and application developers can't take advantage of them for their own development."

Java is another example of this, where you have integers and strings that are built in, but then arrays and dictionaries and things like that are not. And one of the thoughts I had, and this was back when it was mostly a research project, a pet experiment, was, well, how much of this can we push into the standard library? How much can we make it open for extension? Because if you build primitive first-class things right into the language, then library developers, application developers, can't take advantage of them for their own development.

It's not the case that language developers know everything and can predict what the world will look like in 20 years. And so more sensibility seemed like a good thing. So early Swift had trailing closures, for example. It had the ability to overload things. It had a lot of the ideas. But particularly in the early days it didn't have generics; it didn't have a lot of the features we wanted to have. It just took a long time to build those out because they were more complicated.

"I think the early days had many, many ideas, but everything got refined, changed, and it's way better than the initial imagination."

I think a lot of the ideas in early Swift really came through. There's also a lot of ideas that did not work out so well. One of the most notorious examples of an early idea was this idea of being able to overload juxtaposition. So if you have X space Y you can make that be a function call, or you can make that mean different things. And one of the reasons that this seemed interesting was control flow. If you think about an if statement, for example, the syntax is an if identifier followed by a condition, followed by a curly brace.

And so one of the things I was interested in from the very beginning was can this be not built into language – can this be a library extension point? And this is where trailing closures became interesting. And it's interesting to see this come back to the Swift world, where people are interested in more library-based control flow constructs and things like that. I think the early days had many, many ideas, but everything got refined, changed, and it's way better than the initial imagination.

"Autoclosures are one of those things that were an innovation driven by the needs of solving a problem."

Paul Hudson: I think having so much in the standard library is huge because I can tell folks, hey, go and look at Bool.swift, go and look at Optional.swift; they're just structs and enums, whatever, to go and look at directly and see how they solve problems. And you'll be amazed how things like && work in Bool.swift – it's so simple! It's a one-liner in Swift, but it's so beautiful that one-liner, so go and see how they solved it and you will learn things from that, which is awesome.

Chris Lattner: That's a great example. Autoclosures are one of those things that were an innovation driven by the needs of solving a problem: how do you get short circuiting behavior, or when you define assert how do you make it so you can define assert() in the library instead of having a macro preprocessor type thing like C does? And so a lot of those small pieces really came from forcing things in the library in ways that other languages in the C family haven't done quite so much.

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