[swift-evolution] Guaranteed closure execution

[Gwendal Roué]

Thank you very much, Félix!

Gwendal

> Le 31 janv. 2016 à 07:17, Félix Cloutier via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> I'd like to pitch this proposal to implement the feature: 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>
> 
> Rationale for some points:
> 
>> Only one closure parameter can be marked as @noescape(once) in a function signature.
> 
> 
> The attribute doesn't specify the order of execution of the closures, so it could have unintended consequences if closure B depends on closure A but closure B is called first. Given the typical use case (the @noescape(once) closure as a trailing closure), I don't think that it's worth it to invest a lot of effort into coming up with a model to decide (and enforce) which closure has to be called first and what to do if either closure throws or something.
> 
>> it is not required to be executed on a code path that throws;
> 
> 
> It may need to be clarified into "must" or "must not", but I can't think about very good examples supporting either case right now.
> 
> Félix
> 
>> Le 30 janv. 2016 à 19:54:19, Rod Brown via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>> 
>> Yes, I agree. Very good points.
>> 
>> +1
>> 
>>> On 31 Jan 2016, at 8:55 AM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> 
>>>> On Jan 30, 2016, at 12:19 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> The "noescape + exactly once" guarantee is useful to the compiler because it allows the closure to *initialize* variables that it captures. The way to think about this is that the closure body is effectively inlined.
>>>> 
>>>> "noescape, but not exactly once" is still useful because you can omit references to self, and know that variable modifications in the closure will be visible after the function call. But you can't perform initialization (because the closure might be called more than once), nor can you be sure variables are initialized after the function call (because the closure might not be called at all).
>>>> 
>>>> "exactly once, but escaping" is an important API contract that should be documented, but if the closure can escape the call, then you still can't perform initialization in the closure, because the order it happens in w.r.t. the function call isn't guaranteed. I might be missing something, but I don't see any reason for this feature to exist, because...well, it isn't really a feature if it can't do anything.
>>> 
>>> +1, exactly right.
>>> 
>>> -Chris
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> 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/20160131/0b4734d3/attachment.html>