[swift-evolution] Guaranteed closure execution

[Chris Lattner]

> On Feb 3, 2016, at 3:00 PM, Félix Cloutier <felixcca at yahoo.ca> wrote:
> 
> Thanks. I have updated the proposal to reflect this.
> 
> One thing that remains unspecified is the behavior when the closure throws. Feedback and opinions would be very welcome here.
> 
> Some alternatives that I can think of:
> 
> disallow throwing from @noescape(once) closures;

I’d strongly prefer this.  Once/if the base proposal is accepted and implemented, we can always expand from there if strong motivation exists for doing so.

-Chris

> allow throwing and allow the error to be re-thrown (and force `once` closures to be executed on throwing paths);
> return the closure error (possibly incompatible with some function return types).
> 
> Félix
> 
>> Le 3 févr. 2016 à 17:18:51, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> a écrit :
>> 
>>> 
>>> On Feb 3, 2016, at 1:21 PM, Félix Cloutier <felixcca at yahoo.ca <mailto:felixcca at yahoo.ca>> wrote:
>>> 
>>> I updated the proposal to address some concerns. It can be found at: https://github.com/zneak/swift-evolution/blob/master/proposals/00xx-noescape-once.md <https://github.com/zneak/swift-evolution/blob/master/proposals/00xx-noescape-once.md>
>>> 
>>> Things that changed:
>>> 
>>> It now says that the closure must be called on code paths where the function throws;
>>> you can have multiple @noescape(once) parameters but they can't make assumptions from one another.
>>> 
>>> I'm not 100% convinced that forcing a call on code paths that throw is always desirable. I've changed it because Chris's support probably means that the feature has better chances of making it, but I'm not convinced yet. 
>> 
>> To be clear, (once) needs to specify either that the closure is guaranteed to be executed on the error path, or that it is guaranteed not to be.  I can see the argument that “guaranteed not” is the best default.  If you think that is the best way to go, feel free to make that be the proposal.  Either way, please mention in “alternatives” that it needs to be one or the other, but could be switched (from whatever you propose) if there is a compelling reason.
>> 
>> -Chris
>> 
>>> If throwing allows me to return without calling the closure, I can write this:
>>> 
>>> do {
>>> 	let foo: Int
>>> 	try withLock(someLock, timeout: 0.5) {
>>> 		foo = sharedThing.foo
>>> 	}
>>> } catch {
>>> 	print("couldn't acquire lock fast enough")
>>> }
>>> 
>>> which would be kind of messy if instead, the closure needed a parameter to tell whether the lock was acquired or not when it runs.
>>> 
>>> Félix
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160203/ceb0cd3a/attachment.html>