你可以异步调度非转义闭包函数吗？(Can you dispatch a non

你可以异步调度非转义闭包函数吗？(Can you dispatch a non-escaping closure function asynchronously?)

我简要理解转义和非转义闭包之间的区别：

函数返回后调用转义闭包。 从我所知道的，这类似于在node.js中处理回调的方式 - 函数立即返回，它们异步执行，并且当闭包/完成块/处理函数内部长时间运行操作的结果时调用回调。 非转义闭包似乎是同步执行的，其中函数本身在长时间运行操作完成之前不会返回。

（我说得对吗？）

阅读更改日志和从Swift 2的@noescape到Swift 3的@escaping （在SE-0103中 ）的理由，看来你可以异步调度非转义闭包。

这是真的？ 可能？

你可以异步调度非转义闭包函数吗？ 如果是这样，怎么样？

奖励点 - 我真的想了解为什么存在转义和非转义闭包的原因：

是否存在异步调度非转义闭包代替转义闭包的实际用例？ 在设计方案中，它表明函数式编程受益于非转义（读取：同步？）是默认的。 这是真的？ 为什么？ 非转义闭包和node.js中的承诺之间是否有任何相似之处？ 如果我对这一切都错了，为什么不把它@async而不是@escaping ？

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?

最满意答案

我无法想象异步调度函数如何可以非转义。 提案中是否有特定声明表明？

关于您的其他问题：

是否存在异步调度非转义闭包代替转义闭包的实际用例？

这应该是不可能的，所以不会有用例:)

在设计方案中，它表明函数式编程受益于非转义（读取：同步？）是默认的。 这是真的？ 为什么？

该提案表示，函数式编程将受益于较少的样板（即必须将所有参数标记为@noescape ）。 由于函数式编程通常需要许多函数 - 主要是非转义的参数，因此这个新的默认值允许函数式算法具有更清晰，更@noescape签名，并减少在任何地方键入@noescape样板。

非转义闭包和node.js中的承诺之间是否有任何相似之处？

不，promises是异步的，可以使用转义闭包而不是非转义闭包在Swift中实现。

如果我对这一切都错了，为什么不把它称为@async而不是@escaping？

因为它们的概念并不完全相同。 转义闭包可以同步执行，但可以保存以便以后执行。 @async描述了执行的本质，但@escaping只意味着闭包将在传递给它的函数返回后执行。 当一个转义闭包执行时，它可能同时或异步地执行。

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 (i.e. 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.