[kelnos]

Ah that's great!

I wonder why they went with a new keyword; I assumed the compiler would opportunistically do TCO when it thinks it's possible, and I figured that the simplest way to require TCO (or else fail compilation) could be done with an attribute.

(Not sure if the article addressed that... I only skimmed it.)

[afdbcreid]

The `become` keyword changes behavior: it drops variables before the return.

[cranky908canuck]

As a user of the feature, it's the caller that needs the guaranteed elimination (and, presumably, is willing to pay for it, in syntax / compile time / run time / cognitive load). The 'zero cost feature' (only pay if used) principle seems broken if the callee has to indicate something special.

The compiler is free to do something clever (eg., two versions of fn Foo(...), one guaranteeing TCE), but as a developer merely using Foo, I don't want to have to decorate it (or, in a library, have it already decorated) to make TCE (not just TCO) possible. That requirement would constitute delving into the internals.

[aw1621107]

> I wonder why they went with a new keyword; I assumed the compiler would opportunistically do TCO when it thinks it's possible, and I figured that the simplest way to require TCO (or else fail compilation) could be done with an attribute.

The first RFC for guaranteed tail calls stated an attribute on `return` was a possible alternative "if and when it becomes possible to attach attributes to expressions" [0]. That was from pre-1.0, though; I believe Rust now supports attributes on at least some expressions, but I don't know when that was added.

The second RFC [1] doesn't seem to discuss keyword vs. attribute, but it does mention that the proof-of-concept implementation "parses `become` exactly how it parses the `return` keyword. The difference in semantics is handled later", so perhaps a keyword is actually simpler implementation-wise?

There's some more discussion on attribute vs. keyword starting here [2], though the attribute being discussed there is a function-level attribute rather than something that effectively replaces a `return`. The consensus seems to be that a function-level attribute is not expressive enough to support the desired semantics, at least. There's also a brief mention of `become` vs. `return` (i.e., new keyword because different semantics).

[0]: https://github.com/rust-lang/rfcs/pull/81/changes

[1]: https://github.com/DemiMarie/rfcs/blob/become/0000-proper-ta...

[2]: https://github.com/rust-lang/rfcs/pull/1888#issuecomment-278...

[phi-go]

The current rfc is here: https://github.com/rust-lang/rfcs/pull/3407

It does have some more discussion on keywords vs attributes and other options.

[vaylian]

From the article:

> Even in a release build, the compiler has not optimized out the stack. As we execute more and more operations, the stack gets deeper and deeper until it inevitably overflows.

[aw1621107]

That touches on why TCO/TCE is desirable, but it doesn't address why the Rust devs chose to use a keyword for guaranteed TCE.

[cranky908canuck]

See my prior comment: IMO it's the caller's issue that (guaranteed) TCE is needed. The callee should not have to do anything.

One of the things I forget to give thanks to the Rust designers for is the default of immutability. I remember my days in a Java environment where policy was "everything needs to be declared final" (so "final" got spattered all over the place) with zero nostalgia. Requiring TCE callees to explicitly represent themselves as TCE-friendly would be the same sort of abomination.

[jakewins]

I feel like I’ve seen elsewhere that the argument there is that you often must have this optimisation working in algos that rely on it or you will get stack overflows. Having a keyword to force it then becomes a very useful thing, vs relying on hopes that future compiler versions and different arch targets will all discover the optimisation opportunity.

[aw1621107]

> Having a keyword to force it then becomes a very useful thing, vs relying on hopes that future compiler versions and different arch targets will all discover the optimisation opportunity.

Having a way to guarantee TCO/TCE is essential for some cases, yes. GP's question, though, was why a keyword specifically and not a hypothetical attribute that effectively does the same thing.

[IshKebab]

A keyword seems nicer to me. I think the only reason to use attributes is to avoid the work of adding actual new syntax, but seeing as they've already done that...