[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