Closures on Andrew Bancroft

Why is it called a “Closure” anyway? A Swift Conceptual Look.

Tue, 06 Jun 2017 04:00:41 +0000

What’s in a name?

If a programming language comes with a named feature, you can be pretty sure it was named that way for a reason. It’s a safe bet that the language designers were purposeful in their naming, so if you can figure out that essential “Why’d they name it that?” question, you might be that much closer to understanding the feature or concept.

Why “closure”?

Now the challenge: Actually figuring out the answer to that “Why?” question.

Swift is being developed in the open, and often times that gives curious minds insight into things like naming decisions. But closures in Swift have been around for longer than Swift has been open sourced.

That being the case, I really couldn’t find much in terms of the conversation around why closures are named “closures”.

Closures exist in other languages, so maybe Swift just borrowed the name. But that doesn’t help us answer the bottom line reason for naming closures “closures”.

Unpacking “closure” (thanks, thesaurus.com!)

So… I set out on a word adventure to help shed some light on what meaning is to be conveyed by the term “closure”.

It’s one thing to know that “closures are self-contained blocks of functionality that can be passed around and used in your code.” (Apple Developer Docs), but seriously — why not just call them “functions”??

Let’s unpack the word if we can. I put “closure” into thesaurus.com, and among the synonyms that I think best clarify the term “closure” in programming languages are these:

Plug
Seal
Cork

In this sense, “closure” seems to convey the idea of keeping something in… enclosing it.

Okay, so what is a closure enclosing? Great question!

Short answer? Variables.

Inevitably, if you peruse the Internet for what closures are, you’ll come across similar definitions to Apple’s, quoted above. Often, intermingled in the various definitions I’ve found, are phrases like “capturing variables” or “closing over variables”.

These phrases always seemed to muddy the water (for me, anyways). It wasn’t entirely clear what “capturing variables” or “closing over variables” meant. Until I saw the synonyms, “plug”, “seal”, “cork”.

Then it clicked…

An example for your imagination

I want you to take a function in Swift, and I want you to imagine the function as an empty swimming pool. Got it in your mind’s eye? Swimming pool. Empty (for now).

It’s runtime, and your Swift program is happily executing along. Then there’s a moment in your program where your function gets called. It begins executing, and suddenly, water comes rushing in filling the pool. A dozen diving coins get tossed into the water as well!

The coins represent the local variables and constants that your function creates to do its work.

Your function executes all the way to the return keyword, and at the precise moment that your function returns, the drain kicks in. Within milliseconds and with tremendous force, all the water is sucked out of the pool.

What do you think will happen to all the coins in the pool?

For this example, let’s just say the answer is, “they’ll go down the drain”. That would correlate pretty well with what normally happens to variables and constants that had been declared within your function when it returns.

Any variables and constants that are created inside a function are purged from memory whenever the function returns… down the drain, if you will.

Unleeeees…

What if, at some point while there’s still water in the pool, you were able to dive in, grab a few of the coins, and bottle them up?

What if you could stick them in a container and plug it with a cork or some other kind of seal?

If you could do that, the coins would survive the torrential drainage of the pool when the plug is pulled (i.e. the function returns). And that’s what I want you to take away from the example.

A closure acts as a mechanism for diving into the pool, scooping up the coins (i.e. variables and constants) it needs, and sealing itself, such that whenever its parent function (the pool) drains, it and the coins inside survive.

Closures in practice

When you hear that closures are “self-contained blocks of functionality that can be passed around and used in your code.”, you may not realize that they can go grab variables from their environment, package them up, and seal themselves tight, thus safeguarding those variables.

As it turns out, every closure you create has this capability built in.

Not all closures need to go out and capture variables, but all closures in Swift can do so if it’s relevant.

And that is what makes closures “closures”.

Why Do We Need to Annotate Escaping Closures in Swift?

Thu, 11 May 2017 17:58:46 +0000

My last entry on escaping closures ended up having way more interaction than I anticipated! It goes to show that you never know what the impact of a piece of writing will have. But that’s a different story… :]

Several readers commented here and on Medium with the question, “Why? Why do we need to mark escaping closures with @escaping?”

Do it yourself, compiler!

Observant minds looked at the compiler’s ability to say, “Hey! This closure can escape – Annotate it with @escaping!” and asked, “Well… why?? If you, compiler, are smart enough to figure out that I need to annotate it, why can’t you just deal with it automatically and let me go about my business?”

Good. Question.

And one that I didn’t know the answer to. So I researched!

Insight from the Swift gurus

As I dug around in the Swift GitHub repository and the Swift Evolution list I found a quote from Chris Lattner that stuck out:

The compiler has enough logic in it to provide a great QoI (Quality of Implementation) experience when a developer doesn’t think about escaping, and tries to escape a closure – it can provide a fixit that suggests adding @escaping.”

Did you catch that?

When the Swift compiler requires us to annotate our APIs with @escaping, that’s its way of doing “quality of implementation”.

Essentially, it’s a red flag saying, “You really ought to think about this whole escaping thing that you just introduced (whether you knew you were doing it or not)… it has significant impact on your implementation and on the caller of your function!”

I see what you did there… Let me help you out…

The Swift compiler, for better or worse, wants to be very… “helpful”…

Some people hate it. I love it.

I want to be told, “Hey, Andrew… you’re about to break stuff – don’t do that.”

I’d rather head off issues during development than at run-time.

How helpful is it, really?

But really… How helpful is this particular compiler error? What value does this fix-it option provide?

Try this: Think about what would happen if the compiler didn’t tell you about the possibility of your function’s closure escaping.

I was working the other day, cruising along writing what I thought was perfectly normal code when I hit this “annotate your function’s closure parameter with @escaping” error, myself.

“@escaping, Huh? What’s that?!”

1 – I wasn’t thinking about escaping closures because
2 – I had no idea that I could think about escaping closures!!

It turns out that this could have been really bad, agreed? Asynchronous behavior in software requires a little more thought than your normal top-down procedural approach.

If the compiler hadn’t stopped me, I could have inadvertently imposed the need to think in terms of dispatch queues or asynchronous callbacks on the users of my API.

Is this only something that “newbies” need to have the compiler’s help with though?

One could argue that I probably should have been aware of this particular feature of Swift — had I been a better developer, maybe I wouldn’t need the compiler to hold my hand so much.

Okay – Fair point. That leads me to one last gleaning from Lattner’s Swift Evolution entry that I’ll comment on before wrapping up.

Writing resilient code

Let me reflect really quickly on one more quote from the Swift Evolution entry before I end for today.

John McCall pointed out that resilience in the type system is different than resilience in practice: An API changing to capture a closure and use it long after it was originally passed is likely to break the clients regardless of whether the type system captures this as an issue. He argues (and the argument is strong IMO) it is better for resilient APIs to default to @noescape, since that forces the author of V2 to think about whether they are breaking their clients. (emphasis mine)

Resilience is all about how clients are affected when you change the API or its implementation.

Suppose that a team mate of mine writes a function… She’s just created an API, true?

Suppose that the function asks for a closure, but for now it’s just a regular old closure. No escaping or anything.

Others on my team are going to start coding against that function’s signature. If the function is honest, it allows me and my team to have expectations about what it’ll do when it executes.

Now suppose that I’m going to work on version 2 of that same API. Only now, I’m going to introduce the opportunity for that closure to escape (maybe intentionally, or maybe accidentally out of ignorance).

Thaaaat’s gonna break my team. For sure.

They’re using the API as it is expecting normal synchronous behavior from the function. Now I’ve gone in and fundamentally changed what their expectations should be.

In other words, I haven’t been very resilient.

The default behavior of closures passed to functions is to be @noescape. If I introduce the possibility for that closure to escape, I need to be red-flag warned about that, because I need to come up with some way to communicate this breaking change to the clients of the API. And/or provide an alternative so that clients of API v1 can still use it as expected.

Most of all, I need to think about the implications of what I’m doing, and sometimes (a lot of the times) that takes prompting.

The bottom line – The compiler is making you think

All of this to say: The compiler is making you think. Not only that, it’s forcing you to conform.

From what I’ve found, that’s the idea behind “why” we need to mark escaping closures with @escaping in Swift.

What in the World is an “Escaping Closure” in Swift?

Wed, 26 Apr 2017 14:41:07 +0000

If you’re mostly in the business of coding up closures to pass off to other functions as callbacks, you may not have run into the concept of an “escaping closure” yet.

When you step out of the role of consuming other peoples’ APIs in to the realm of creating your own (and you do this all the time!), this is where you’ll likely run into the concept of an “escaping closure” in certain scenarios.

I want to start off by defining the term. Then I’ll throw out a couple of usage scenarios that cause us to need to think in terms of a closure “escaping”.

Definition

First, a definition, shall we?

A closure is said to escape a function when the closure is passed as an argument to the function, but is called after the function returns.
–Apple Developer Documentation

So apparently, you can get yourself into the situation where you’re designing a function that takes in a closure as one of its parameters:

func doSomething(completion: () -> Void) { ... }

Furthermore, it appears that it’s possible to find yourself in a situation where the closure will execute, but somehow, it doesn’t get executed until after the function it got passed into returns. So it would go something like this:

Call doSomething and pass it a closure of Type () -> Void
doSomething performs its work and returns
The closure you passed (the one of Type () -> Void) gets executed

Weird, huh? How in the world can that happen? I’ll talk about that in a second.

The point for now is this: whenever you’re in a situation like this where the closure that you pass to a function gets executed after the function you passed it to returns, you’ve got an “escaping closure” on your hands.

As an API consumer, you might not know or care about the escap-y-ness of the closure.

As an API designer (which again, could be yourself, if you’re the one writing the definition of doSomething(completion:)), you have to care, because the Swift compiler will be angry with errors if you don’t.

So how do “escaping closure” scenarios happen?

Escaping closure scenarios

Here are a few scenarios that give rise to escaping closures.

Storing the closure as state

Apple’s docs give an example of appending a closure that’s passed into a function to a mutable array of closures within your class/struct:

1var completionHandlers: [() -> Void] = []
2
3func doSomething(completion: () -> Void) {
4    completionHandlers.append(completion)
5}

Presumabley then, at some later time after doSomething returns, all of the completion handlers in the array will be looped over and executed (or something like that)…

As you can see, this follows the 1. Pass closure, 2. doSomething returns, 3. Closure executed pattern we had before, doesn’t it?

So this is one scenario that could give rise to an escaping closure, IF you designed your system this way.

Whenever you take the closure, store it as state, and then execute it at a later time, the closure is “escaping” the function it got passed into.

Asynchronous asynchronous callbacks

No, I didn’t get repetitively redundant there. Well… I did, but it was on purpose. :]

Supposing that you’re working on your doSomething(completion:) function.

Within it, you make a call to another function that performs an asynchronous action and asks for a completion closure of its own.

What if you only want to call the completion handler that was passed into doSomething after the asynchronous action of the other function completes. That is, what if you only want the two completion handlers to be executed together:

1func doSomething(completion: () -> Void) {
2    doSomeOtherAsynchronousThing(completion: {
3    () -> Void in
4    // code that executes after the other asynchronous thing is done
5    completion()
6    })
7}

Here, you’ve got this nested asynchronous behavior going on, don’t you? Asynchronous asynchrony is happening.

Whenever you defer the execution of a closure to a time that’s after the “parent” function returns, you’ve got an “escaping closure” on your hands.

Declaring “this is an escaping closure!” in code

Whenever you’re implementing a function that introduces the possibility for a closure passed to it to escape, you’ll know it.

The Swift compiler will complain, and your app won’t build:

What do you do to fix it?

It’s pretty simple. In the declaration line of your function, you need to add the @escaping attribute right before the closure’s Type declaration:

doSomething(completion: @escaping () -> Void)

Wrapping up

My goal was to shed some light on the concept of “escaping closures”. With the definition and the example scenarios that give rise to escaping closures, my hope is that things are a little more clear for you. Sound off in the comments if you’re still struggling, or if you’ve run across other scenarios requiring you to use the @escaping attribute!

Resolving “Variable used within its own initial value” Error in Swift

Mon, 20 Oct 2014 13:50:52 +0000

While experimenting with a few things today, I experienced this compiler error:

Variable used within its own initial value

Let me describe the situation I was in…

I was playing (in a playground, no less) with closures, trying to mimic some behavior that I’ve recently learned about in Scala. Essentially, I was trying to implement a factorial function as a closure, and I was trying to do it recursively (that is, without using a for/while loop). Here’s what I wanted to do:

1let factorial = {
2    (n: Int) -> Int in
3    if (n == 0) {
4        return 1
5    } else {
6        return n * factorial(n - 1)
7    }
8}

If you’ve seen factorial before, the above implementation isn’t new. The “base case” that will let the recursion stop is the expression if (n == 0), and the recursive case is in the else block, where factorial gets called again within its own body’s definition. Only problem is… this doesn’t work in Swift 1.0.

Apparently, the closure (which is being initialized and assigned to the constant named “factorial”) hasn’t had a chance to fully initialize itself before the name factorial is used within the body.

The frustrating part is that I really didn’t want to type the letters v-a-r to implement my solution. But alas, as Stack Overflow says, the following solution to the “initial value” error works:

 1var factorial: (Int) -> Int
 2factorial = {
 3    (n: Int) -> Int in
 4    if (n == 0) {
 5        return 1
 6    } else {
 7        return n * factorial(n - 1)
 8    }
 9}
10
11factorial(5)
12// Produces the correct result of 120

Of course, there’s absolutely no reason for the implementation to be a closure – I was simply experimenting. Here’s the solution that I actually prefer… a good ole named function definition:

 1func factorial(n: Int) -> Int {
 2    if (n == 0) {
 3        return 1
 4    } else {
 5        return n * factorial(n - 1)
 6    }
 7}
 8
 9factorial(5)
10// Produces the correct result of 120