为什么Swift 3需要@转义注释？

Question

我读了这篇问答和Cocoacasts博文，我完全理解什么是< code>@escaping注释。

但老实说，我不明白我们为什么需要它。

上述Cocoacasts博客文章指出:

默认情况下，使闭包不转义有几个好处。最明显的好处是性能和编译器优化代码的能力。如果编译器知道闭包是非转义的，它可以处理内存管理的许多细节。

但是，Swift编译器可以确定＜code＞转义

这也意味着您可以在非转义闭包中使用self关键字而不会出现问题，因为闭包是在函数返回之前调用的。在闭包中不需要使用对self的弱引用。这是一个很好的好处，你可以免费得到。

但是，如果闭包参数被标记为@escaping我仍然可以传递使用对 self 的强引用的闭包，并且编译器不会显示任何警告。实际上，如果默认情况下@escaping闭包捕获的所有引用都是弱的，并且应用特殊关键字使它们变强，那将更有用。

我还认为,< code>@escaping注释是通过显式声明这个闭包参数不会对函数体进行转义来使代码自文档化的方法，但是调用方这样做的目的是什么呢？它不限制闭包定义的方式，也不阻止调用方使用强引用。所以我只希望调用方仔细查看函数签名，并采取适当的措施(比如使用弱引用)。

因此，问题是为什么我们真的需要Swift 3中的@转义闭包，以及在哪些情况下我们离不开它？

更新：

我知道不转义闭包不能传递给函数，该函数的闭包参数标记为@escaping：

func testNoEscape(f: () -> ()) {
    f()
}

var storeF: (() -> ())?

func testEscaping(f: @escaping () -> ()) {
    storeF = f
}

func tryPassNoEscapeToEscaping(f: () -> ()) {
    testEscaping(f: f)
}

导致编译错误：

passing non-escaping parameter 'f' to function expecting an @escaping closure

但这是@escaping关闭带来的唯一真正的限制，它看起来像是围绕自己建立的，并没有带来任何其他好处。

更新2

虽然我正确地表达了上述想法，但我的最后一个问题不准确。

真正的问题是，如果编译器可以自己检测转义闭包，并且< code>@escaping注释不对参数值施加任何限制，那么我们为什么还需要< code>@escaping注释？

在我看来，如果编译器不允许我们在逃避闭包（如使用self和其他强引用）时做一些坏事，那将更有用。或者，如果转义闭包是某种特殊类型，那么在调用具有转义闭包参数的函数时，我们必须提到这一点：

func f(c: () -> ()) { // c is escaping from f somehow
    // ...
}

f escaping { // have to use `escaping` keyword 
    // ...
}

因此，调用方不必查看 f 签名即可知道 c 正在转义，因为如果它尝试将非转义闭包作为转义闭包参数值传递，它将出现编译错误。

在当前的实现中，希望在其代码中使用f的开发人员必须查看f，以了解c将逃逸，这是不安全的，因为这要求最初编写此代码并在以后修改它的任何人都必须详细了解f签名，这不可靠，并且此类代码没有自我记录。

我明白也许我的问题不适合这样。很抱歉。

如果是这样的话，如果我不能从在Swift语言和编译器中实现转义逻辑的人那里得到答案，我将稍后关闭它。

Answer 1

编译器可以查看您创建的代码，但无法查看您用作预编译框架一部分的代码（截至目前，由于ABI问题，没有Swift框架，但将来会有）。

也许他们可以将这种转义需求仅应用于“公共”函数，但这看起来会有点不一致。最好只是通过工具提示插入关键字。

Answer 2

也许还有其他原因，但最主要的原因是要传达您的闭包将超过您将其传入的函数的持续时间。这可能会对程序的行为产生非常复杂的影响，因此明确这一点很重要。

此外，闭包的“逃逸性”是公共API的一部分。编译器无法查看正在调用的编译库。如果没有@escaping属性公开传递闭包无法转义的事实，编译器无法从编译后的代码中自行推断出闭包。

Answer 3

非转义闭包可以做转义闭门无法做的事情。它们是完全不同的动物。

例如，非转义闭包可以引用self的属性，而无需明确表示self。这是因为，作为非转义（即它在收到后立即执行），它没有以某种棘手的方式捕获self并导致保留循环的危险。

而且，非转义闭包可以在＜code＞inout＜/code＞参数上关闭。但这对于逃避关闭毫无意义，是不允许的。

如果一个闭包似乎有时需要< code>self，有时不需要< code>self，有时允许对< code>inout进行闭包，而有时不需要，这将是非常神秘的。< code>@escaping注释使得这种规则区分清晰一致。