我有一个看起来像这样的函数:
func test(closure: () -> ()) { let localClosure = { closure() } localClosure() }
这只是一个例子,并没有完全反映我遇到的问题,显然在这里我可以直接调用封闭!
应该清楚的是,在上面的代码中,封闭无法逃脱.但是,我收到错误:
Closure use of non-escaping parameter ‘closure’ may allow it to escape
现在,如果localClosure以某种方式转义,我会理解这个错误,但它不会逃脱.我甚至尝试将localClosure注释为@noescape(即使该属性在Swift 3中已弃用),并根据我得到的警告:
@noescape is the default and is deprecated
解决方法
“If
localClosure
is,by default,non-escaping,then why …”
根据以下评论中的讨论(感谢@Hamish),我们可以在Swift 3.0中说明关于非参数闭包的以下事实:
>默认情况下,它们与人们可能认为的相反,是@escaping.由于在Swift 3中不推荐使用@noescape(参见例如Xcode 8 release notes或Swift evolution proposal SE-0103),这意味着如果不使用已弃用的方法,则不能使非参数闭包非转义.
>如the following evolution thread所述,非参数闭包缺少@noescape属性是一个缺失的特征(有些回归,因为这不是Swift 2.2中的限制),但未来不一定要实现(如果我要理解苹果开发者乔丹罗斯在联系进化线索中的答案.
>然而,我们可能(仍)将已弃用的@noescape属性应用于非参数闭包以使其无法转义,但随后将显着提示不正确的警告(如下所示,强调我的),现在已报告为@Hamish的一个错误,见bug report SR-2969.
“
@noescape
is default and is deprecated”
总而言之,localClosure是@escaping,这自然意味着不能允许它包装test(…)的非转义闭包参数闭包.
[†]通过非参数闭包,我指的是不是函数参数的所有闭包,即没有作为参数提供给函数的闭包.
作为附注,你可能已经知道了你的问题:如果我们希望像你的例子一样处理/包装它,我们可以自然地将闭包标记为@escaping.
func test(closure: @escaping () -> ()) -> () -> () { let escapingLocalClosure = { closure() } return escapingLocalClosure }
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。