<p dir="ltr">Just curious, is there a deeper-than-semantic difference between a @noescape(once) closure and an inlined closure? </p>
<br><div class="gmail_quote"><div dir="ltr">On Sun, Apr 24, 2016, 5:58 PM Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On Apr 23, 2016, at 3:18 AM, Gwendal Roué via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div style="word-wrap:break-word">Hello Andrew,<div><br></div><div>I'm rather embarrassed: the initial design of this proposal was based on a modifier of @noescape:</div><div><br></div><div><span style="white-space:pre-wrap">        </span>func f(@noescape(once) closure: () -> ()) { … }</div><div><br></div><div>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" target="_blank">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><br></div><div>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><br></div><div>So the proposed @noescape(once) syntax is now confusing as it would mix a type attribute and a argument qualifier.</div><div><br></div><div>I don't quite know how to escape this:</div><div><br></div><div><span style="white-space:pre-wrap">        </span>// two @ signs</div><div><span style="white-space:pre-wrap">        </span>func f(@noescape @once closure: () -> ()) { … }</div><div><br></div><div><span style="white-space:pre-wrap">        </span>// Implies @noescape</div><div><div><span style="white-space:pre-wrap">        </span>func f(@once closure: () -> ()) { … }</div><div><br></div><div>I'd like advice from competent people before I would attempt a rewrite of the proposal.</div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>Hi Gwendal,</div><div><br></div><div>I don’t think that the movement of @noescape affects the approach: I’d suggest that a proposal (e.g. Felix’s) go with:</div><div><br></div><div><span style="white-space:pre-wrap">        </span>func f(closure: @noescape(once) () -> ()) { … }</div><div><br></div><div>The semantics are clear: the closure is guaranteed to be called exactly once on all normal and “throw” paths. Paths that do not return in either of those ways (e.g. a call to abort) do not need to call the closure.</div><div><br></div><div>IMO, this is a small scope proposal that is likely to be accepted.</div></div></div><div style="word-wrap:break-word"><div><div><br></div><div>-Chris</div></div></div><div style="word-wrap:break-word"><div><div><br></div><br><br><blockquote type="cite"><div><div style="word-wrap:break-word"><div><div>Gwendal Roué</div><div><br></div><div><blockquote type="cite"><div>Le 10 avr. 2016 à 23:26, Andrew Bennett <<a href="mailto:cacoyi@gmail.com" target="_blank">cacoyi@gmail.com</a>> a écrit :</div><br><div>Sorry I missed that scrolling back through the history, that proposal looks great. It doesn't look like it has<span></span> been submitted as a pull request to swift-evolution yet though.<br><br>On Sunday, 10 April 2016, Gwendal Roué <<a href="mailto:gwendal.roue@gmail.com" target="_blank">gwendal.roue@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Felix Cloutier already wrote one: <a href="https://github.com/zneak/swift-evolution/blob/master/proposals/00xx-noescape-once.md" target="_blank">https://github.com/zneak/swift-evolution/blob/master/proposals/00xx-noescape-once.md</a><div><br></div><div>Do you think it needs to be rewritten?</div><div><br></div><div>Gwendal Roué</div><div><br><div><blockquote type="cite"><div>Le 10 avr. 2016 à 14:56, Andrew Bennett <<a>cacoyi@gmail.com</a>> a écrit :</div><br><div>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></span><div><div><br>On Sunday, 10 April 2016, Gwendal Roué <<a>swift-evolution@swift.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hello all,<div><br></div><div>I was wondering if this topic had evolved in anyway since its original introduction.</div><div><br></div><div>@noescape(once) would still be a useful addition to the language!</div><div><br></div><div>Gwendal Roué</div><div><br></div><div><br></div><div><br><div><blockquote type="cite"><div>Le 3 févr. 2016 à 22:21, Félix Cloutier via swift-evolution <<a>swift-evolution@swift.org</a>> a écrit :</div><br><div><div style="word-wrap:break-word">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">https://github.com/zneak/swift-evolution/blob/master/proposals/00xx-noescape-once.md</a><div><br></div><div>Things that changed:</div><div><br></div><div><ul><li>It now says that the closure must be called on code paths where the function throws;</li><li>you can have multiple @noescape(once) parameters but they can't make assumptions from one another.</li></ul><div><br></div><div>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><br></div><div><div>do {</div><div><span style="white-space:pre-wrap">        </span>let foo: Int</div><div><span style="white-space:pre-wrap">        </span>try withLock(someLock, timeout: 0.5) {</div><div><span style="white-space:pre-wrap">                </span>foo = sharedThing.foo</div><div><span style="white-space:pre-wrap">        </span>}</div><div>} catch {</div><div><span style="white-space:pre-wrap">        </span>print("couldn't acquire lock fast enough")</div><div>}</div></div><div><br></div><div>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><div>
<br><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">Félix</span>
</div>
<br></div></div></div>_______________________________________________<br>swift-evolution mailing list<br><a>swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></div></blockquote></div></div>
</div></blockquote></div><br></div></div></blockquote>
</div></blockquote></div><br></div></div>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div></div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>