4 ms·

Will this allows us to get TCO? I'm used to writing recursive functions and miss TCO all the time.

• pcwalton 11y ago
  In theory it could allow for sibling call optimization by rewriting those functions into loops. It would not allow full unrestricted TCO--that would require both ABI work and thorny high-level design issues around destructors that may well not be solvable at all. However, in practice LLVM already has full support for sibling call optimization internally, so implementing such an optimization at the MIR level wouldn't really buy us anything over what we already have.
  • cm3 11y ago
    Then maybe rustc ought to have diagnostics that warn if a recursive function won't be optimized fully, and then I can either avoid recursion or rewrite to fit into the optimizer, but having to appease a changing optimizer isn't what I'd call maintainable code, so a function attribute might make more sense.
    • geofft 11y ago
      There's a reserved and unimplemented keyword "become", which is like "return" except it requires that it can optimize the tail call (and is a compile-time error if it can't). See this comment: https://github.com/rust-lang/rfcs/issues/271#issuecomment-189386398 https://github.com/rust-lang/rfcs/issues/271#issuecomment-18... Nobody's tried implementing it recently, though.
  • Ericson2314 11y ago
    How about non-sibling TCO provided their are no drop obligations? I'll gladly write the boilerplate of manually calling `drop` to get the ball rolling here.
    • dbaupp 11y ago
      LLVM can already do sibling TCO in cases like that. Of course, it isn't guaranteed at a language level.
      • Ericson2314 11y ago
        Oh nice.