Is there anything you would change in Swift?

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

There's been lots of language change from the very early days to now, do you have any regrets – any things you wished had been changed that now it's too late?

Chris Lattner: Yes. I mean, there's lots of things. They're generally details. We talked about initialization, for example. One super minor one that grates on me, frequently, is that map(), filter(), and reduce() don't follow the naming convention.

And so things like that are really annoying. At the time it was a discussion about, okay, well we want this to be familiar. Also, map(), filter(), and reduce() got installed before the naming conventions did. And so they predated that; they just never changed as part of Swift 3.

There are other things, we talked about trailing closures and the way that it works with keywords, not great. There's a lot of features like that, that are not perfect.

"At the time it was a discussion about, okay, well we want this to be familiar. Also, map(), filter(), and reduce() got installed before the naming conventions did. And so, they predated that, so they just never changed as part of Swift 3."

Overall though, I think that there's lots of examples in the nitty gritty, how name lookup works, for example. So, if you want me to complain about things, one of the important things about Swift is this notion of you get modular type checking. And so, if you look at a Swift function, you're required to write the type signature for the function.

And not all languages are like that. Particularly, a lot of functional languages like Haskell, you don't have to write type signatures for functions. And what that means is that if you do code completion in the middle of a file, for example, in Haskell, you have to type check a tremendous amount of the world in order to realize what the local types are that you're working with.

Whereas in Swift, if you refer to a function, it has a fully elaborated type. And so you don't have to go under this body and type check it to understand the signature for a function, for example, right? And this is one of the things that's important for interactive compile times, and Xcode experience, and things like this.

"There's a variety of pretty nitpicky things that I think are not ideal. A lot of those, I think we can make better. But the one that is most grating is map, because it's an important thing, it's very visible. It's one of the things people learn early on."

And so Swift is very good that way. Except we kind of missed when it came with property declarations. Instead of property declaration, you can say var x = foo() – the x doesn't have a type. And so, actually, if you refer to x, now you have to go type check, what is that expression? And that expression could be a closure. It could be an arbitrarily complicated thing. And so we lose out on some of the things like that.

And so there are things like that. I mean, associated type inference. There's a variety of pretty nitpicky things that I think are not ideal. A lot of those I think we can make better. But the one that is most grating is map(), because it's an important thing, it's very visible. It's one of the things people learn early on, and it really cuts against the consistency in the rest of the language.

Paul Hudson: So actually, I did a video with Sophie, my daughter. We did a video for UIKonf in May, and filter() was one of the things you mentioned because we talk about how a filter works. Not only does it break the naming conventions, but also doesn't work the way my brain works.

"If we were sufficiently motivated, we could actually add mapping and other things like that, form maps, whatever the right name is, and that would make the language more consistent."

Like, we're filtering in things, and filtering out things. It's the complete inverse of what you expect and you take it for granted. I take it for granted, at this point, we just assume that's how it works. We're used to it, it's baked into our heads now. But for everyone learning it it’s this massive speed bump – why does it do that? And you forget, because you move on.

Chris Lattner: That's exactly right. And this is one where making the name better, either by adding a keyword to the closure or by putting in the base name, would have been way better.

And that's an example where if we were sufficiently motivated, we could actually add mapping() and other things like that, formMap(), whatever the right name is, and that would make the language more consistent. We can deprecate the old names. We as a community can move forward. I think there are the questions: how fast can we phase out the old names? Which would not be fast because everybody uses them. But we could at least start by nudging the world towards the new names, if someone wanted to push on that.

Paul Hudson: One Evolution proposal I often point folks to is SE-0056, which was, from you, to allow trailing closures in guard conditions. And the reason I do this is because, it didn't get through, it was rejected. And the discussion is, from a historical perspective, this was an oversight. It wasn't supposed to work this way. It wasn't supposed to be different to this. I forgot to limit the requirement when we decided to re-syntax the guard else. Whoops, can we now fix that? And the answer was, "No." I mean, it's part of the language now, that is now the de facto Swift version.

And that's fascinating that it became itself through a literal evolution. It happened over time and it changed, and things happened, and life got in the way sometimes. And that resulted in the Swift we have today.

"I think there are the questions. How fast can we phase out the old names? Which would not be fast because everybody uses them. But we could at least start by nudging the world towards the new names."

Chris Lattner: Yes. I mean, these are the little things, and I'm looking at it now, this is one of those really weird things that probably nobody runs into. But, yes. I mean, this is one that, also, maybe we should relook at in light of other changes.

But, yes. I mean, mistakes happen and nobody's perfect. And I think that one of the interesting things about languages is that they are used by a lot of people. And so, you talk about filter and how it works with your brain. But the problem with that is that is very visible to the community at large. And I think those are the kinds of things that even though it's painful, we should try to figure out how to fix.

The other things that almost nobody hits, and they're just weird corner cases that only a compiler knows about. Those are less important to me, because they don't really undermine the full experience of using Swift.

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