Can you dispatch a non-escaping closure function asynchronously?

Question

My brief understanding of the difference between escaping and non-escaping closures:

• Escaping closures are invoked after the function returns. From what I can tell, this is similar to the way callbacks are handled in node.js — the function returns immediately, they execute asynchronously, and the result of the long-running operation inside the function is handled when the closure/completion block/callback is called.
• Non-escaping closures appear to be execute synchronously, where the function itself doesn't return until the long-running operation is complete.

(Did I get that right?)

Reading the change log and justification for moving from Swift 2's @noescape to Swift 3's @escaping (in SE-0103 ), it appears you can asynchronously dispatch non-escaping closures.

Is this true? Possible?

Can you dispatch a non-escaping closure function asynchronously? If so, how?

Bonus points — I really want to understand why both escaping and non-escaping closures exist:

• Is there a practical use-case for asynchronously dispatching a non-escaping closure in place of an escaping closure?
• In the design proposal, it suggests that functional programming benefits from non-escaping (read: synchronous?) being the default. Is this true? Why?
• Is there any similarity between non-escaping closures and a promise in node.js ?
• If I'm wrong about all of this, why not just call it @async instead of @escaping ?

Answer 1

I can't conceive of how an asynchronously dispatched function can be non-escaping. Is there a specific statement in the proposal that suggests that?

Regarding your additional questions:

• Is there a practical use-case for asynchronously dispatching a non-escaping closure in place of an escaping closure?

This shouldn't be possible, so there wouldn't be a use-case for it :)

• In the design proposal, it suggests that functional programming benefits from non-escaping (read: synchronous?) being the default. Is this true? Why?

The proposal says that functional programming would benefit from having less boilerplate (ie having to mark all parameters as @noescape ). Since functional programming usually entails many functions-as-parameters that are predominantly non-escaping, this new default allows functional-style algorithms to have cleaner, less cluttered signatures and reduces typing the the @noescape boilerplate everywhere.

• Is there any similarity between non-escaping closures and a promise in node.js?

No, promises are asynchronous and would be implemented in Swift using escaping closures, not non-escaping closures.

• If I'm wrong about all of this, why not just call it @async instead of @escaping?

Because they are not exactly the same concept. An escaping closure may execute synchronously, but be saved off for execution at a later time. @async describes the nature of execution, but @escaping means only that the closure will be executed after the function it was passed to returns. When an escaping closure does execute, it might do so either synchronously or asynchronously at that time.