<div dir="ltr">Hello,<div><br></div><div>I've updated the proposal and created a pull request. Please let me know if it needs further updates</div><div><a href="https://github.com/apple/swift-evolution/pull/103">https://github.com/apple/swift-evolution/pull/103</a><br></div><div><br></div><div>TJ</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 8, 2015 at 1:08 AM, Chris Lattner via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> 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"><span class="">On Dec 7, 2015, at 3:18 PM, Mark Lacey <<a href="mailto:mark.lacey@apple.com" target="_blank">mark.lacey@apple.com</a>> wrote:<br><div><blockquote type="cite"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite"><div><div style="word-wrap:break-word"><div><blockquote type="cite"><div><div style="word-wrap:break-word"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">It seems like this could also be handled by passing continuations that should be run on the return paths of callees. The continuation a function passes to its callee would wrap the continuation passed to it by its caller, so they would get executed in the original order. That’s an ABI change though, and a potentially expensive one.</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">We’ve considered doing something like this as an optimization to enable more proper tail calls in other cases (e.g. for the ARC case where you release after return). This would be done by cloning callees, and adding a new parameter. It’s not clear how worthwhile it would be to pursue this, and how expensive it would be in terms of code bloat.</div></div></div></div></blockquote><br></div><div>Why not just make “tail” a modifier on return that guarantees you’ll either get a tail call, or a compile time error?</div><div><br></div><div>Use of “tail return foo()” in a context with a defer in flight could/should just produce that compile time error then. This would provide the predictable programming model that people are seeking, and can provide good QoI so people know how to solve the problem if they really want the tail call (remove or change the defer).</div></div></div></blockquote><div><br></div>If you really don’t want to support defer in functions that have tail calls, I think what you're suggesting is the right approach. As Joe pointed out the optimization I had in mind wouldn’t be necessary if we had support for just transferring ownership at the point of these tail calls (as opposed to the retain/release we emit around the call for these arguments today).</div></div></blockquote><br></div></span><div>I would really prefer that a “tail return” not change the semantics of the function, it merely is an assertion that the tail call is guaranteed. This means that defer cannot be used, but we can exploit the “early destroy’s are ok” aspect of ARC to solve its issues.</div><div><br></div><div>I agree that this isn’t enough to solve the calling convention issue, an attribute or magic for self recursion seems fine to me.</div><div><br></div><div>-Chris</div><br>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=3FGfocPbgxkNkmje7djckg9Iw-2BGYY3X6RxJ1tkUXKCreiBC-2BKbHSPknw3rSZnM42gvilhW6ELFZrJHQbRELMxS9shqVdGwTupn7vXDNqTPkJiwgOAXChPwd4yZSoZaCxaDaqzFisHV4E2LZaRyvEvNv3u-2BEpDXtnmEDZPoUxs67GQxDv2UfIzL8kGEwFcDuYGUARfFX-2B-2FE9-2Bcwn1ugcIGk3-2FHWM0fosGIW64esbxdS4-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
</div>
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">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>
<br></blockquote></div><br></div>