<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=""><div class="">@Matthew: The @autoclosure was actually an accident; I meant @noescape. :) That said, yes, I think that we'll often want @noescape(once) on @autoclosure parameters.</div><div class=""><br class=""></div><div class="">As for "once?" seems to me that calling a non-escaping closure a second time on accident isn't a very frequent mistake, and when it happens it ought to be very easy to debug. It also doesn't add benefits outside of this verification, so it's unclear to me that the it pulls its own weight. Even as I was writing the @noescape(once) proposal, I was having doubts that it itself would pull its own weight.</div><div class=""><br class=""></div><div class="">@Brent: no matter how useful it is, we can't reasonably prove that an escaping closure is called exactly once without move semantics (and move-only closures). For now, if @once is distinct, it needs to be accompanied by @noescape.</div><div class=""><br class=""></div><div class="">@Gwendal: that's one solution. A third solution would be to enforce that @noescape(once) parameters are executed in parameter order.</div><div class=""><br class=""></div><div class="">Do you have any example of UIKit where a function accepts two closures that could reasonably be marked @noescape(once)?<br class=""><div class="">
<br class="Apple-interchange-newline"><span style="color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;" class="">Félix</span>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">Le 1 févr. 2016 à 09:31:53, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> a écrit :</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=""><div 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=""><br class=""></div><div class=""><div class=""></div><blockquote type="cite" class=""><div class=""><font color="#5856d6" class="">func foo() {</font></div><div class=""><font color="#5856d6" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>let bar: Int</font></div><div class=""><font color="#5856d6" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>withNoEscape { bar = 1 }</font></div><div class=""><font color="#5856d6" class="">}</font></div><div class=""><font color="#5856d6" class=""><br class=""></font></div><div class=""><font color="#5856d6" class="">func withNoEscape(@autoclosure(once) closure: () -> ()) { /* snip */ }</font></div></blockquote></div><div class=""><br class=""></div>Looking back, I do think that there should be a way to exit from `withNoEscape` without calling the closure, so yes, throwing should imply that the closure wasn't executed. If it's possible that `foo` swallowed an error from a throwing `withNoEscape`, the compiler should assume that the variables within haven't been initialized:</div></div></blockquote><br class=""></div><div class="">I’m glad to see an @autoclosure func in this thread. We will want to be able to use this feature with @autoclosure in addition to @noescape.</div><div class=""><br class=""></div><div class="">As far as exiting without calling the closure, I suggest `@noescape(once?)`. The `?` indicates the closure may or may not be called, but <b class="">will not</b> be called more than once.</div><div class=""><br class=""></div><div class="">This would be handy in the case of the short-circuiting boolean operators, for example:</div><div class=""><br class=""></div><div class="">@warn_unused_result func &&<T : BooleanType, U : BooleanType>(_ lhs: T, @autoclosure(once?) _ rhs: () throws -> U) rethrows -> Bool</div><div class=""><br class=""></div><div class="">-Matthew</div></div></div></blockquote></div><br class=""></div></body></html>