4 ms·

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 de

by vaylian 7mo ago

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 7mo ago
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.
- jakewins 7mo ago
  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 7mo ago
    > 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 7mo ago
      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...
- cranky908canuck 6mo ago
  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.

by vaylian 7mo ago

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 7mo ago

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.

jakewins 7mo ago
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 7mo ago
  > 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 7mo ago
    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...
cranky908canuck 6mo ago
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.