guaranteed tail call elimination

[rust-highfive]

Tracking issue for postponed PR #81

[ranma42]

In the PR several people mentioned that they preferred become over be.
Even tough the PR has been postponed, would it be a good idea to reserve become for tailcalls before releasing 1.0?

I'm not suggesting to implement tail call elimination, just reserving the keyword for the future.

[ticki]

What's the state of this?

[steveklabnik]

@ticki status is "nobody has submitted a new RFC yet"

[ticki]

I might make one when I get time, if no-one is working on this.

[hatahet]

In Scala, annotating a method with @tailrec would make the compiler enforce that that method's implementation is tail recursive, otherwise it is a compiler error.

Would something similar be a good fit for Rust (e.g. tagging functions with #[tailrec], or something of that sort)?

[steveklabnik]

@hatahet we reserved a 'become' keyword, the prevailing idea seems to be that return -> become would indicate that the function should guarantee TCO

[hatahet]

Does that mean that having become at the tail position would always be required?

fn loop1() {
  // ...
  become loop1()
}

otherwise, what if it were mixed as follows:

fn loop1() {
  // ...
  if foo {
    // ...
    become loop1()
  } else {
    // ...
    loop1()
  }
}

[steveklabnik]

I would imagine so, but that's the work that an RFC proposing the syntax would have to work through :)

[ConnyOnny]

How about we first implement this with a trampoline¹ as a slow cross-platform fallback implementation, and then successively implement faster methods for each architecture/platform?
This way the feature can be ready quite quickly, so people can use it for elegant programming. In a future version of rustc such code will magically become fast.

¹ see here for a small and to-be-generalized example trampoline: https://gist.github.com/ConnyOnny/5917e4e549056f6a3db01a5277480f6b