<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 30, 2016, at 10:17 PM, Félix Cloutier via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I'd like to pitch this proposal to implement the feature:&nbsp;<a href="https://github.com/zneak/swift-evolution/blob/master/proposals/00xx-noescape-once.md" class="">https://github.com/zneak/swift-evolution/blob/master/proposals/00xx-noescape-once.md</a><div class=""><br class=""></div><div class="">Rationale for some points:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">Only one closure parameter can be marked as&nbsp;@noescape(once)&nbsp;in a function signature.</blockquote></div><div class=""><br class=""></div><div class="">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.</div></div></div></blockquote><div><br class=""></div><div>I don’t see a reason to have this limitation. &nbsp;Definitive initialization has to be able to generate conditional code for partially initialized cases anyway, e.g.:</div><div><br class=""></div><div>var c : C</div><div><br class=""></div><div>if … {</div><div>&nbsp; &nbsp;c = C()</div><div>}</div><div>c = C() &nbsp;// could be an initialization or an assignment.</div><div>use(c)</div><div><br class=""></div><div><br class=""></div><div>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).</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class="">it is not required to be executed on a code path that throws;</blockquote></div><div class=""><br class=""></div><div class="">It may need to be clarified into "must" or "must not”, </div></div></div></blockquote><div><br class=""></div><div>Yes, I agree it needs to be one or the other.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">but I can't think about very good examples supporting either case right now.</div></div></div></blockquote></div><br class=""><div class="">I think the simplest model is that it should be “must”. &nbsp;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.</div><div class=""><br class=""></div><div class="">-Chris</div></body></html>