<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="">Hello Andrew,<div class=""><br class=""></div><div class="">I'm rather embarrassed: the initial design of this proposal was based on a modifier of @noescape:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func f(@noescape(once) closure: () -> ()) { … }</div><div class=""><br class=""></div><div class="">But since the 0049 proposal has been accepted (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0049-noescape-autoclosure-type-attrs.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0049-noescape-autoclosure-type-attrs.md</a>), @noescape is no longer an argument qualifier, but a type attribute.</div><div class=""><br class=""></div><div class="">The `once` discussed here can not be part of the type: if noescape can understandably be part of the type, the fact that a function guarantees it will call a closure once is a quality of that function, not of the closure.</div><div class=""><br class=""></div><div class="">So the proposed @noescape(once) syntax is now confusing as it would mix a type attribute and a argument qualifier.</div><div class=""><br class=""></div><div class="">I don't quite know how to escape this:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// two @ signs</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func f(@noescape @once closure: () -> ()) { … }</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// Implies @noescape</div><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>func f(@once closure: () -> ()) { … }</div><div class=""><br class=""></div><div class="">I'd like advice from competent people before I would attempt a rewrite of the proposal.</div><div class=""><br class=""></div><div class="">Gwendal Roué</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">Le 10 avr. 2016 à 23:26, Andrew Bennett <<a href="mailto:cacoyi@gmail.com" class="">cacoyi@gmail.com</a>> a écrit :</div><br class="Apple-interchange-newline"><div class="">Sorry I missed that scrolling back through the history, that proposal looks great. It doesn't look like it has<span class=""></span> been submitted as a pull request to swift-evolution yet though.<br class=""><br class="">On Sunday, 10 April 2016, Gwendal Roué <<a href="mailto:gwendal.roue@gmail.com" class="">gwendal.roue@gmail.com</a>> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">Felix Cloutier already wrote one: <a href="https://github.com/zneak/swift-evolution/blob/master/proposals/00xx-noescape-once.md" target="_blank" class="">https://github.com/zneak/swift-evolution/blob/master/proposals/00xx-noescape-once.md</a><div class=""><br class=""></div><div class="">Do you think it needs to be rewritten?</div><div class=""><br class=""></div><div class="">Gwendal Roué</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">Le 10 avr. 2016 à 14:56, Andrew Bennett <<a href="javascript:_e(%7B%7D,'cvml','cacoyi@gmail.com');" target="_blank" class="">cacoyi@gmail.com</a>> a écrit :</div><br class=""><div class="">Hi, not beyond this thread that I have seen. I think it's worth you summarizing this thread in a formal proposal and putting it up for discussion or submitting it as a PR :)<span class=""></span><div class=""><div class=""><br class="">On Sunday, 10 April 2016, Gwendal Roué <<a href="javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">Hello all,<div class=""><br class=""></div><div class="">I was wondering if this topic had evolved in anyway since its original introduction.</div><div class=""><br class=""></div><div class="">@noescape(once) would still be a useful addition to the language!</div><div class=""><br class=""></div><div class="">Gwendal Roué</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">Le 3 févr. 2016 à 22:21, Félix Cloutier via swift-evolution <<a class="">swift-evolution@swift.org</a>> a écrit :</div><br class=""><div class=""><div style="word-wrap:break-word" class="">I updated the proposal to address some concerns. It can be found at: <a href="https://github.com/zneak/swift-evolution/blob/master/proposals/00xx-noescape-once.md" target="_blank" class="">https://github.com/zneak/swift-evolution/blob/master/proposals/00xx-noescape-once.md</a><div class=""><br class=""></div><div class="">Things that changed:</div><div class=""><br class=""></div><div class=""><ul class=""><li class="">It now says that the closure must be called on code paths where the function throws;</li><li class="">you can have multiple @noescape(once) parameters but they can't make assumptions from one another.</li></ul><div class=""><br class=""></div><div class="">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. If throwing allows me to return without calling the closure, I can write this:</div><div class=""><br class=""></div><div class=""><div class="">do {</div><div class=""><span style="white-space:pre-wrap" class=""> </span>let foo: Int</div><div class=""><span style="white-space:pre-wrap" class=""> </span>try withLock(someLock, timeout: 0.5) {</div><div class=""><span style="white-space:pre-wrap" class=""> </span>foo = sharedThing.foo</div><div class=""><span style="white-space:pre-wrap" class=""> </span>}</div><div class="">} catch {</div><div class=""><span style="white-space:pre-wrap" class=""> </span>print("couldn't acquire lock fast enough")</div><div class="">}</div></div><div class=""><br class=""></div><div class="">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.</div><div class=""><div class="">
<br class=""><span style="font-family:'Lucida Grande';font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">Félix</span>
</div>
<br class=""></div></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div></div>
</div></blockquote></div><br class=""></div></div></blockquote>
</div></blockquote></div><br class=""></div></body></html>