Recorded – watch the full episode on YouTube.
One recent Swift addition was quite controversial, to the point where I can say the number without the name and you know what I'm talking about. It’s SE-0279 – what are your thoughts on multiple trailing closures?
Chris Lattner: I guess a couple of things with this, I think that this proposal is one of the most recent ones. It's been very controversial. I've tried to stay out of it mostly. I think it was a design mistake for Swift to not support multiple trailing closures from the beginning. I think that was a misstep on its own. I think that also early Swift got the keyword argument syntax with trailing closures wrong.
I think that right now the way it works, if you're not familiar, is that if you use trailing closures it implicitly suppresses a keyword for the closure. And in hindsight, that's a terrible thing. It should be that you were required to specify the keyword if it was present in the signature, or if it's an under bar, then you don't specify it. Therefore all, of the standard library functions that use trailing closures would use an under bar in practice.
"I think a lot of the controversy has come down to which half of language people prefer or which they're biased towards thinking it's the most important half and it's kind of this no-win situation."
Unfortunately, we don't have that world. And so I think a lot of the discussion evolved into, well, what is the least bad way to solve this problem that's most consistent with what have, and how do we get multiple trailing closures to be more consistent with half of the language? And I think a lot of the controversy has come down to which half of language people prefer or which they're biased towards thinking it's the most important half and it's kind of this no win situation.
I think it's great we now have this capability. So I think that making multiple trailing closures possible is a good thing. I think that some people are making the claim that, “it's a mess right now, but we can clean up later.” I think I'm more skeptical of that – I think that what we have is just going to be one of those accidents of the past, bad decisions that were the wrong thing that then you play forward and you feel bad about but, no matter what happens, I don't think it unearths the world or causes great cataclysmic disasters anywhere. It's just a word. That's kind of how I feel about it.
"The scope of this is so minor that I don't think it will functionally really matter in the end but we'll see."
Paul Hudson: Back to Joe Groff, who said, “this too shall parse” – classic Joe.
Chris Lattner: Yeah, exactly. So I think that there's lots of unfortunate things in the world that we live in. And so the scope of this is so minor that I don't think it will functionally really matter in the end but we'll see. We can talk about it in two, three years when we have a little bit more hindsight.
Paul Hudson: I think that's one of the things I have to remember as well and I think a lot of folks need to keep in mind is that everything in evolution looked strange at first because it is new. That's the point of it. Of course, it's new. It looks strange. We're not used to it. Give it six months, give it three months, give it any period of time, live with it for a while. This is why I'm really glad to see the standard library previewing package to let some things bake a bit longer. Let's try it out in practice, see what we think before it gets put into the language forever.
"There are other language communities that have realized that any new thing that gets proposed, people want to add a very visible keyword to be like warning, warning, warning, new thing happening."
Chris Lattner: You're absolutely right. I mean there are other language communities that have realized that any new thing that gets proposed, people want to add a very visible keyword to be like warning, warning, warning, new thing happening. But then you play forward a few years and it's like, of course, you have that feature. Why are we worried about this?
Swift actually went through this too. So dynamic member lookup was one of the features that when we were discussing it, certain people were like, "Oh my god, if we have this feature, the entire world is going to come unraveled and we're not going to be able to talk about anything and nothing. The sky will fall and we don't know so we're going to add this attribute on a class." And so you have to put an attribute on the class. That somehow will make it feel safer. In reality, the world has not come unraveled. In reality, nobody cares about the keywords so we should just ignore the keyword. It's fine. But you're right. This is human nature.
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 Spend less time managing in-app purchase infrastructure so you can focus on building your app. RevenueCat gives everything you need to easily implement, manage, and analyze in-app purchases and subscriptions without managing servers or writing backend code.
Link copied to your pasteboard.