[swift-evolution] Proposal: Tail Call Optimization keyword/attribute

[T.J. Usiyan]

Hello,

I've updated the proposal and created a pull request. Please let me know if
it needs further updates
https://github.com/apple/swift-evolution/pull/103

TJ



On Tue, Dec 8, 2015 at 1:08 AM, Chris Lattner via swift-evolution <
swift-evolution at swift.org> wrote:

> On Dec 7, 2015, at 3:18 PM, Mark Lacey <mark.lacey at apple.com> wrote:
>
> 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.
>
> 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.
>
>
> Why not just make “tail” a modifier on return that guarantees you’ll
> either get a tail call, or a compile time error?
>
> 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).
>
>
> 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).
>
>
> 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.
>
> I agree that this isn’t enough to solve the calling convention issue, an
> attribute or magic for self recursion seems fine to me.
>
> -Chris
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160130/3dce4c2a/attachment.html>