[swift-evolution] Guaranteed closure execution

[Chris Lattner]

> On Jan 30, 2016, at 10:17 PM, Félix Cloutier via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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.

I don’t see a reason to have this limitation.  Definitive initialization has to be able to generate conditional code for partially initialized cases anyway, e.g.:

var c : C

if … {
   c = C()
}
c = C()  // could be an initialization or an assignment.
use(c)


The caller side would just have to conservatively prove that the closure bodies initialized any values they touch before using them (or that they were initialized already at the call site).

>> it is not required to be executed on a code path that throws;
> 
> 
> It may need to be clarified into "must" or "must not”,

Yes, I agree it needs to be one or the other.

> but I can't think about very good examples supporting either case right now.

I think the simplest model is that it should be “must”.  IMO, the only most common (and again, simplest) semantics here is that the closure is called exactly once on any path to a return or throw.

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