Closure in Swift : The Painful one !

Shubham Bakshi
May 1 · 9 min read

As per Swift Documentation :

Closures are self-contained blocks of functionality that can be passed around and used in your code

Anyone trying out closures for sometime now must have read this quote and be like

Atleast i was !

To put it in simple words :

A closure is a block of code that you can assign to a variable

let someVariable = 10

Both the constants defined above are essentially the same, an Int type .

The only difference between the two is that, the first one is written as we have been writing all along and the second one is written using a closure.

I know, i know that’s a really messed up way to declare a variable ! Let’s move on.

I bet you must have seen the declaration below —

func pretendItsACoolName() { 
Okay , Okay !

Yeah, It’s a function . What’s more, is that it’s actually a closure . You see functions are special kind of closures . In fact, there are three kinds of closures

  1. Global functions : Closures that have a name and do not capture any values.
  2. Nested functions : Closures that have a name and can capture values from their enclosing function.
  3. Closure expressions : Unnamed closures written in a lightweight syntax that can capture values from their surrounding context.

If you want to know more about Global and Nested functions, check this out .

But the main star of this article is Closure expression a.k.a. closure (duh?) .

But why is the name Closures and not Nameless Functions (or, maybe, he-who-shall-not-be-named) .

Well, Closures can capture and store reference to any constants and variables from the context in which they are defined. This is known as closing over them, hence the name closures

Let’s get started

Okay enough with the nomenclature, let’s get down to business !

You can define a closure like this :

let myNickname: (String) -> String = { (name: String) in

That’s a lot of things to digest at once, I’ll try to break it down bit-by-bit .

  • Closure Type (String) -> String : This tells the compiler that we will have a closure which will take a single parameter , String and will return a String as well. The input parameter/s for our closure has to be written inside round-braces () , even if we have just one (like above), otherwise the compiler will go nuts .
  • Closure Expression (name: String) in : Like i said above, all the parameters for the closure goes inside round-braces () . (name: String) is our parameter list. The in keyword is a separation between closure’s parameter list and the closure’s definition/body.
  • Closure Definition/Body : What follows after the in keyword and before the closing } is the body of the closure. Here you can write whatever rocket science logic you need to write.
  • Closure Call myNickname(“Boxy”) : A Closure is always called using the name of the variable that we assigned the closure to, followed by () (In case we don’t have any parameters for our closure). If we have some parameters for our closure , like a String in our case, we need to pass that parameter like we did in our closure call

Cut the Code !

Now, we have defined our above closure with the most lengthy way we can , wanna see some shorthand and compiler-inference magic ?

Let’s first move our closure type into a typealias as it’s really good practice to use typealias in your code as it improves readability and reusability.

typealias closureType = (String) -> String

Next we will use shorthand properties in our code, $0,$1 …. . If you have never worked with them , it seems scary at first.

To break it down , all they signifies is the number of parameters that will be passed to our closure. In our case, we are just passing a String parameter so we will access that using $0 . If we had 2 input parameters , we would access the first parameter with $0 and second parameter with $1.

Since we will be using shorthand properties, we don’t need to write

(name: String) in

so we can get rid of that !

So our code now will look like this :

typealias closureType = (String) -> String

We can reduce this code even more by removing the return keyword and bringing the whole closure definition to a same line. That’s compiler-inference magic for you

typealias closureType = (String) -> String

However, the above code will only work (without explicitly writing the return keyword) when we have only a single line inside our closure body. That’s because when we don’t use the return keyword inside the body, and the closure has to return a String value and we just have a single line of code in our body (that too a String), the compiler is smart enough to figure it out that, the particular String (that is in our closure body), is to be returned, so it doesn’t go nuts this time. But when you add one more line to the body of closure , the compiler will jump all over.

Okay, so what if there is no parameter and no return type for the closure as well . Well, in that case we use () -> () or () -> Void as our closure type . If you look carefully, you have seen () somewhere else in Swift.

Yup, they are tuples. They are used to contain data of dissimilar types.

Void is an alias of an empty tuple (). When a function or closure doesn’t return anything, it’s return type is Void.

BONUS : Just like you cannot mutate the parameters of the function, as they are implicitly declared let, but you can, if you have declared those parameters as inout , same is the case with Closures.

A Sneak !

Now, If you noticed, i did a little trick on you guys. When i started the article with a closure example, i used

let someCoolerVariable = {

And in the example above , i used

typealias closureType = (String) -> String

You noticed yet ? Okay, okay i will tell you. Look at how i called the first closure and how i called the second closure.

The first one (someCoolerVariable) will be called right after i defined it and the second one (myNickname) will be called when i explicitly call it .

Let me take you on a ride —

let aStubbornClosure = {

When you run this code, the output on console will be : I will be called no matter what

Now these, stubborn closures, are really helpful and popular in cases where you are creating your UI Elements programatically . As the elements will be initialised and ready for use as soon as the closure body is completed.

Plus, the type of both are not same. aStubbornClosure is of type () while aNiceClosure is of type () -> () . Which means that aStubbornClosure , is not actually a closure, but a definite value ! That’s why, when you run it, you’ll get a warning, as the compiler infers its type to be () which , to be honest, is really confusing.

To break it down, consider this final example

let aCoolVariable = {

Type of aCooleVariable is Int which is not a closure , whereas the type of aNotSoCoolerVariable is () -> Int , which is a closure .

Trailing Closures

A Trailing Closure is a concept which states that if , a function takes last parameter as a closure, then while calling that function,

  1. We can omit/remove the name of the closure parameter inside function
  2. We can close the function parameter list with ) and then write our closure body within { } after the closing ) .
func someFunctionThatTakesAClosure(closure: () -> Void) {

Capture List

How many times have you seen the following code when you’re working with Closures inside View Controllers

someClosure = { [weak self] in

The thing inside the square-brackets [] are actually the Capture list . If you want to know the basics of capture list, you can checkout Capture List — Bob The Developer .

Just like [ weak self ] , we have [ unowned self ] which helps us in preventing memory leaks that occurs due to strong reference cycle. Most of the times, whenever we are using self inside the closures, we need a weak or unowned reference to it.

So , what’s the difference between weak and unowned ?

You typically use unowned when the closure and the captured value (self in our case) will always refer to each other, and will always be deallocated at the same time. We can use [unowned self] in a view controller, where the closure will never outlive the view controller.

You typically use weak when the captured value at some point becomes nil. This can happen when the closure outlives the context it was created in, such as a view controller that’s deallocated before a lengthy task is completed. As a result, the captured value is an optional .

Escaping closures

Prior to Swift 3.0 , the closures were escaping by-default but after 3.0, closures have been made no-escaping by-default . But what exactly is the difference ?

Escaping generally means that the closure will escape or outlive the scope of the context it is being called in (say a function) and exist elsewhere . As the execution ends, the scope of the passed closure have existence in memory, till the closure gets executed.

In case of non-escaping closures, defined by @noescape,

  1. We pass the closure as function argument
  2. Do some additional work with function
  3. Function runs the closure
  4. Function returns the compiler back

In case of escaping closures,defined by @escaping,

  1. We pass the closure as function argument
  2. Do some additional work with function
  3. Function returns the compiler back
  4. At some later stage, closure get executed as and when required

In my opinion, @escaping closures are really useful when dealing with Asynchronous network request , where response from the server comes after some delay , when even the function that called the service has returned.

Use Cases

The most prominent use cases of Closures can be :

  • Completion Handlers
  • Programatically creating UI Elements
  • Higher Order Functions
  • Syntactic Sugar

Well, that’s it from my side !

You can connect with me on LinkedIn 👱🏻 or can get in touch with me via other channels 📬

Shubham Bakshi

Written by

iOS Developer at CDAC R&D, Pune | My articles have memes ❤