Is Swift Evolution working well?

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

In the early days of Evolution, anyone could submit language proposals. That's changed: before you submit a proposal you've got to have an implementation to show what you're asking for is possible. How do you think that's affected the evolution process?‌

Chris Lattner: That actually gets back to one of your earlier questions about how fast Swift changes. So the purpose of making that change was really to slow down the language. It's to raise the bar on the kinds of changes we're willing to take. And the effect it had most profoundly is it made language changes harder, but it did not directly affect standard library changes. Because standard library is relatively accessible and you can implement library features much easier than language features.

"And the effect it had most profoundly is it made language changes harder, but it did not directly affect standard library changes."

So it definitely slowed down evolution of the language. Whether or not you think this is a good thing or a bad thing depends on how much exciting change in the language you'd like to see. So the day that Swift magically gets rewritten, the Swift compiler gets rewritten to be in Swift, I think that would make the impact of that be lower. But I think that it has slowed down evolution.

I think that's generally a good thing. One of the reasons that this got put in place was not specifically to slow things down. It was because a lot of proposals were proposed like, “wouldn't it be great if we did this?" And then the community, the core team, everybody, says, “yes, it would be great,” and then implementation never happened.

And so that's one of the risks that you have with an open source project. In a normal open source project you can't make a schedule where you say, “we're going to do a release in September, and we're going to get done this and this and this and this and this. Okay. Right. Go." And then you get to August and you're like, "Well, what happened?" And like, "Oh, I went on summer break." "Oh, well I had a final exam and it was really hard." You can't plan that way.

And so, this is one of the ways to improve planning and make sure that things that do get approved actually do get implemented. But it's mixed. I mean, I think it does reduce the inclusivity of the community. So I think that's a bad thing.

"So one of the reasons that this got put in place was not specifically to slow things down."

Paul Hudson: I think one of the most notable gaps from a submission to implementation was number 68, the universal Self – expanding Self to class members and value types. And it was put in a while ago, but it landed in Swift 5.1. It took a number of years.

I think, if I remember correctly, the eventual result was to catch the error as it was triggered and do a cheeky workaround to put the correct replacement in its place instead. And it worked, and people are like, "Oh, that does work. Brilliant. Let’s just use that." And it's a great language feature, but it took a long time to figure out how to make it happen.

"I think that encouraging the community or encouraging more people that like working on compilers to get involved, I think is a good thing."

Chris Lattner: Yes. And another thing that I think is valuable over time is for the community around Swift to learn more about working on the compiler, and the compiler is hard. I mean, it's a complicated piece internally, and so that is not super accessible. And so that's just the way it is. But I think that encouraging the community or encouraging more people that like working on compilers to get involved, I think is a good thing.

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