Swift Closures Cheat Sheet
General Notes
- Closures are reference types
- Global functions are closures that have names and capture no values
- Closures are commonly used as callback functions for network API requests
- The parameter to the .sorted() and .sort() functions accept closures--which illustrates that closures can also be used in non-asynchronous code.
- Closures can be anonymous blocks (like lambdas in C#), they can be code blocks assigned to variables (for repeated use), or as standalone functions (also for repeated use).
- A closure will capture any constant and variable it references from its containing scope, which has an impact on ARC reference counting and can create retain cycles if proper care isn't taken.
Returning a Closure from a Function
Closures are commonly used to return data from functions asynchronously, such as a data service that fetches information from a file system or web API. In the following examples, the function fetchData simulates a function that makes a web API call, then returns some result via a closure.
func fetchData(withSimulatedDelay delay: Double,
completion: @escaping
(_ average: Double, _ dataArray: [Int]) -> Void) {
let numEvents = Int.random(in: 1..<10)
var arr = [Int]()
var total = 0.0
for _ in 0..<numEvents {
let j = Int.random(in: 100..<1000)
total += Double(j)
arr.append(j)
}
DispatchQueue.global(qos: .background)
.asyncAfter(deadline: .now() + delay) {
completion(total / Double(numEvents), arr)
}
}
The meaning of the @escaping decoration is discussed below, but isn't important to understand at this point.
Passing in a Closure as a Function
In this first example, the closure is a named function.
func closureAsFunction(average: Double, array: [Int]) {
print(average, array)
}
fetchData(withSimulatedDelay: 0.1, completion: closureAsFunction)
As is probably obvious, when fetchData calls completion(..), it's actually calling closureAsFunction(...).
Passing in a Closure as a named block
Next, let's define a block of code with a variable (or constant) name, and pass that to fetchData
let closureAsConstant: (Double, [Int]) -> Void = { average, array in
print(average, array)
}
fetchData(withSimulatedDelay: 0.2, completion: closureAsConstant)
Closures as functions or blocks can be very useful when the blocks are well defined in advance and will be re-used many times (or even twice). While the next examples (unnamed blocks) are more commonly used, don't forget about these first two alternatives. They can keep code more modular and may often support DRY (Don't Repeat Yourself) principals in your design.
Passing in a Closure as an unnamed block
Closures don't have to be defined as functions or assigned to variable names, but instead can be unnamed blocks. These are similar to lambdas in other languages.
fetchData(withSimulatedDelay: 0.5,
completion: { (average : Double, array : [Int]) in
print(average, array)
})
fetchData calls the block via its parameter named completion. Think of the block ({..}) as an inner function that doesn't have a name and is coded at the point it's used.
Trailing Closures
If a closure is the last parameter of a function's signature, and an unnamed block is the closure, then closure's parameter name can be omitted. This call has the same effect as the previous one.
fetchData(withSimulatedDelay: 0.5) { (average : Double,
array : [Int]) in
print(average, array)
}
Swift 5.3+ includes support for multiple trailing closures. See below for examples.
Syntax Variants for Trailing Closures
// Include return types. Helpful to avoid confusion of return types
fetchData(withSimulatedDelay: 0.5) { (average : Double, array : [Int]) in
print(average, array)
}
// But the types are optional, since fetchData has already
// told the compiler what the types should be
fetchData(withSimulatedDelay: 1.0) { (average, array) in
print(average, array)
}
// The parends around the return parameters are
// usually not required
fetchData(withSimulatedDelay: 2.0) { average, array in
print(average, array)
}
// Unused parameters can be replaced with underscore
fetchData(withSimulatedDelay: 2.0) { _, array in
print(array)
}
Using typealias for Closure Signatures
It can sometimes be be useful to use typealias to define the parameters returned to closures.
Useful Scenarios
- If the parameters are numerous, the typealias can reduce repetitive typing
- The
typealiascan increase readability of code by having less syntax in the signature for functions accepting closure parameters. - When many functions accept closure parameters having the same signature, defining the parameter list in a typealias can be helpful. Since changes to closure parameter lists are defined centrally, a refactor of the parameters only needs to be changed in one place.
First, define the closure signature as a typealias
typealias DataServiceResponse = (Double, [Int]) -> Void
Then any function that returns data to closures with this signature can use the typealias in the parameter list rather than the full closure signature. Here's fetchData defined with the typealias*:*
func fetchData(withSimulatedDelay delay: Double,
completion: @escaping DataServiceResponse) {
.
.
.
}
Pass the closure to fetchData identically as before
fetchData(withSimulatedDelay: 1.0) { average, array in
print(average, array)
}
Multiple Trailing Closures
Prior to Swift 5.3, only the last closure could be defined with the trailing syntax (i.e. excluding the closure parameter name). From Swift 5.3, trailing closures can be stacked.
Keep in mind that trailing closures will not be marked with names. If your code would be confusing to read with multiple trailing closures, you can still use named closure blocks as before.
First, you need to define a function that accepts a list of closures as final parameters:
func fetchData(withSimulatedDelay delay: Double,
arrayResponse: @escaping (_ average: Double, _ array: [Int]) -> Void,
setResponse: @escaping (_ set: Set<Int>) -> Void,
dictResponse: @escaping (_ dictionary: [Int:Int]) -> Void) {
let numEvents = Int.random(in: 1..<10)
var arr = [Int]()
var set = Set<Int>()
var dict = [Int:Int]()
var total = 0.0
for _ in 0..<numEvents {
let j = Int.random(in: 100..<1000)
total += Double(j)
arr.append(j)
if !set.contains(j) {
set.insert(j)
}
dict[j] = 1
}
DispatchQueue.global(qos: .background)
.asyncAfter(deadline: .now() + delay) {
// Call each of the closures
arrayResponse(total / Double(numEvents), arr)
setResponse(set)
dictResponse(dict)
}
}
Then call the function, and list each closure block one after the other
fetchData(withSimulatedDelay: 0.5) { average, array in
print(average, array)
} setResponse: { set in
print(set.sorted(by: >))
} dictResponse: { dict in
print(dict.values)
}
Each closure block above is independent of the others, and there's no reason to expect they all return at the same time. fetchData could make three separate web API requests, with the 2nd or 3rd returning data from the remote web server much later than the 1st. The closure for each is called whenever fetchData calls each closure.
Escaping Closures
If a closure is called by the function it's passed to after that function has ended, the closure is called escaping. These types of closures are very common when using closures as call-back functions for asynchronous operations such as web API requests or file I/O requests.
In fetchData, the DispatchQueue..asyncAfter ensures that the closure will be called after fetchData has returned. Its closure is therefore escaping fetchData.
Functions that may accept escaping closures are decorated with @escaping at the point the closure parameter is defined:
func fetchData(completion: @escaping (_ average: Double,
_ events: [Int]) -> Void)
If the compiler sees that fetchData is designed to call a closure after it returns (e.g. on an asynchronous thread), a compiler error will be issued.
Weak/Unowned Self
When passing an @escaping closure to another object, care should be taken to avoid allowing the closure to unnecessarily hold a retain lock on the object that created it. Doing so may delay deinit of the object that created the closure object (in the best case), and could create retain cycles that lead to memory leaks (in the worse case).
But don't panic – avoiding these scenarios is usually easy.
A captured variable is declared weak via the* [weak variableName]* decoration. A variable so decorated will be redefined as optional within the closure block, and the reference to it from within the closure block will not contribute to its retain count. This will help avoid excessively long ARC locks, retention cycles and/or memory leaks.
The closure should then verify any weak captured variable is not nil before accessing it.
Marking captured variables weak is almost always a good idea when passing a closure as an @escaping closure.
In the following code, the weak self notation turns self into an optional, and tells the compiler that the block shouldn't increment the retain count of self.
Checking for non-nil of the (now optional) self within the block avoids a crash in case self was destroyed before the block was called.
fetchData(completion: { [weak self] (array : [Int]) in
print("self is nil? \(self == nil)")
self?.workDone = true
print(array)
})
[unowned self] is another option, which has the same effect on retain count, but doesn't redefine the captured variable as optional within the closure block. Keep in mind, though, that an [unowned self] variable could become nil if its retain count goes to zero before the closure block is called, so checking for nil may still needed when this alternative is used.
[unowned self] is a bit like telling the compiler "trust me, I've got this"