[swift-evolution] Guaranteed closure execution
Gwendal Roué
gwendal.roue at gmail.com
Fri Jan 29 06:47:05 CST 2016
Yes, Thorsten.
Brent: I’m sorry if the title of the thread is not precise enough. The goal here is to let such a closure guarantee variable initialisation, as below:
func f(@noescape(once) closure: () -> ()) {
closure()
}
let x: Int // Not initialized
f { x = 1 }
print(x) // Guaranteed to be initialized
Such closure can not escape. Hence @noescape(once), not @once.
dispatch_sync() is often cited in this mailing list, and we all want that it declares its argument as @noescape. Now it would be even better if it would declare it as @noescape(once).
Gwendal
> Le 29 janv. 2016 à 13:11, Thorsten Seitz <tseitz42 at icloud.com> a écrit :
>
> But if the closure can escape it is difficult to guarantee that it is executed at all (e.g. in your examples such as dispatch_async).
>
> -Thorsten
>
> Am 29. Januar 2016 um 11:58 schrieb Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org>:
>
>>> You are right Jacob, a modifier `@noescape(once)` would be better, as it would help compiler distinguish between assignment and initialization of captured variables.
>>>
>>> The utility of such a new feature is maybe tiny, but clear: it extends the opportunities to declare variables before initializing them. The Swift 1 to 2 transition has already extended those opportunities, so we’re just following an existing trend, here.
>>
>> I actually think that `once` is orthogonal to `noescape`. There are a *lot* of closures that are not noescape, but are called exactly once, such as dispatch_async and most completion handlers.
>>
>> --
>> Brent Royal-Gordon
>> Architechies
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160129/c6356b89/attachment.html>
More information about the swift-evolution
mailing list