Chris Lattner explains closures

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

Many people find closures the hardest thing to learn in Swift. And it's true, they are a hard thing. So again, Chris, you wrote Swift: how would you explain closures to them?

Chris Lattner: Well, see that's an interesting question. I haven't thought about that nearly as much. This is not a thing that you would teach a new learner in the first day of Swift. This is something that I think comes up when you're talking about existing frameworks that take function pointers so they take closures, right? So I think there it really would be grounded in the API you're trying to teach.

"UIKit is not designed for progressive disclosure of complexity. It is an amazing framework but it's a power user framework. So it was not built with that design premise and so I think that there you kind of get thrown in the deep end quite quickly to achieve simple things. I think SwiftUI is much more promising this way."

So if you're teaching map(), filter(), and reduce() kinds of things and so you're talking about collection processing kinds of operations, then I think you explain it in terms of the context of what you're doing. So you're saying, "Hey, if you want to do a filter, how do you know what kinds of elements to select?" Well, you need a little expression and you explain it mechanically in terms of, "Well, you just put that expression inside of curly braces." So this is how we pass an expression, right?

The challenge with teaching programming in the context of something like UIKit is that UIKit comes back to this idea of playgrounds being easier to teach as well. UIKit is hard, right? UIKit is not designed for progressive disclosure of complexity. It is an amazing framework but it's a power user framework. So it was not built with that design premise and so I think that there you kind of get thrown in the deep end quite quickly to achieve simple things. I think SwiftUI is much more promising this way, where I think that the design center for it.

The folks working on designing the APIs really thought more about like let's make simple things really simple. Let's make it so you can get something done with very little code. Let's make it so you can grow and scale to more complexity as you want to and you can introduce new concepts progressively.

I don't know if that's a consequence of Swift tuning the culture a little bit and saying this is the right way to do things or maybe there's Swift language features that enable that that aren't really practical in UIKit, I don't know, or history. There's many different possible causes for that. So with closures, I think it's really about the context in which you explain them which really comes down to the APIs.

Paul Hudson: A small question here, a bit of a tangent from Robert J. Clegg who says talking of closures, “why is the in part of the closure syntax there? Why is the word in part of the syntax?"

"I will tell you that if somebody knows what in stands for or means, then they should tell me because I don't know either."

Chris Lattner: Okay, Paul, can I be honest with you? You're not going to just get mad at me or anything?

Paul Hudson: Just between you and me and nobody else at all. Totally secret. Go ahead.

Chris Lattner: Okay, don't tell anybody. It might be because nobody could come up with a better word. Don't tell anybody, okay. But it could be that this was discussed at length a million times both internally to Apple and on the mailing list and it might be that nobody came up with a better idea.

I will tell you that if somebody knows what in stands for or means, then they should tell me because I don't know either.