Understanding escaping closures Swift - ios

Question

Need help with escaping closures.
I understand that the definition of escaping closures is If a closure is passed as an argument to a function and it is invoked after the function returns, the closure is escaping.
I believe there are a few scenarios where escaping closures are necessary.
Setting an outside variable as the passing closure
I understand this because the variable lives even after the function returns.
Asynchronous operations
Things like Dispatch.main.async{} or Network Request.This is the part the I don't quite understand. I understand that Dispatch.main.async{} runs on a different thread and that async operations take a while to complete hence the name async. However, I cannot understand how these operations outlive the scope of the function.

Answer 1

When you call DispatchQueue.main.async{} you are creating a closure (a block in Objective-C) that is sent to the given dispatch queue. Your function will then continue running after the async call and could end before the block has a chance to run on the DispatchQueue. The closure has "escaped"!
The code in the block will actually be run when the block reaches the front of its DispatchQueue
The async doesn't mean that the operation will take a long time, it means that this function (the one calling async) will not pause to wait on the block to complete.
(if you DID want to pause and wait for the operation to complete, you could call sync instead of async).

Answer 2

When you do asynchronous work it might escape the current scope cause, by definition, it won't be waited for its completion.
This is also why the terminology completion is used for those closures adopted in asynchronous code for the delivery of results.
Here's an example, assuming queue is a DispatchQueue and someHugeWork() -> R is a synchronous function which returns a result R:
func doItSync() -> R {
var result: R!
queue.sync {
result = someHugeWork()
}
// the function has to wait for the code submitted synchronously
// on the queue.
return result
}
func doItAsync(completion: #escaping (R) -> Void) {
queue.async {
let result = someHugeWork()
completion(result)
}
// work was submitted asynchronously on the queue, hence the function
// just returns, therefore the completion closure might escape this
// scope.
}
Now, obviously in this case doItSync() does not really make sense, since it'll block the current thread until someHugeWork() has executed on a different queue. That is also why you can return the result from its scope: it waits for it. I've only added this to let you see the difference between synchronous code and asynchronous code for returning a result.
On the other hand doItAsync(completion:) just returns immediately without having to wait for someHugeWork() to complete on a different queue, hence it won't block the current thread.
Since you've submitted this work asynchronously on the queue you now have no control about when it will be executed and that is also why your only way to return the result from someHugeWork() is by using a completion closure, which has to be captured inside the work item submitted asynchronously… If you think about it for a moment it'll be as if such completion closure is stored to be retrieved by the queue at a later time when it will executes the work item submitted asynchronously (you said in your question that you did got the concept of storing a closure).
Now let's also see a method which doesn't need an escaping closure, that'll be the body parameter of Sequence's forEach(_:) method: this method executes the given closure on every element of the sequence, that'll be as in doing:
func forEach(_ body: (Element) -> Void) {
for element in self {
body(element)
}
// the function returns only after the for-in loop has completed,
// hence body closure only executes in the scope of this method,
// thus it never escapes.
}
(for the sake of simplicity I've omitted the throwing annotations)
In this case the body closure never escapes forEach(_:) method's scope, therefore it doesn't need to be annotated as #escaping: it will only executes inside the for-in loop which has to complete before the method can return.