5 ms·

Just add the @tailrec annotation -- then the compiler will complain loudly if you break tail calls.

lmm 1y ago
Yes, the problem is if you didn't add it but the compiler was still silently TCOing your function, until one day it doesn't.
- Quekid5 1y ago
  Sure, but if you're relying on the TCO, you kind of have to actually state that, regardless? (At least if you want to avoid accidental regressions.) I don't see any way around having to state your intent (as a programmer) for this. It's just a semantic difference in behavior unless your Abstract Machine allows for just ignoring the possibility of stack overflow entirely.
  - lmm 1y ago
    > I don't see any way around having to state your intent (as a programmer) for this. I want a way to state that my intent is to not rely on the TCO. Even a second explicit annotation for "do not TCO this function" would be better than what Scala currently does (but frankly TCO is surprising enough to debug that I think it should be opt-in rather than opt-out).
    - Quekid5 1y ago
      > I want a way to state that my intent is to not rely on the TCO. How would that work? You want a nontail keyword to indicate that intent explicitly? I guess I could imagine a scenario where you want to de-optimize a TCO into a non-TC... but I mean... that's got to be rare enough to just not bother with? EDIT: Also, this is the exact opposite of your comment which I replied to. Make up your mind on what you want and we can maybe find a way to achieve it
      - lmm 1y ago
        > How would that work? You want a nontail keyword to indicate that intent explicitly? Either that, or to not have TCO applied if I don't set a keyword (which I'd prefer). > I guess I could imagine a scenario where you want to de-optimize a TCO into a non-TC... but I mean... that's got to be rare enough to just not bother with? Sometimes I know that a given function will eventually need to be non-TC, in which case I want a way to make it non-TCO now. More commonly a junior team member just hasn't thought about TC-ness at all, in which case I'd rather the function not be TCOed and fail-fast than be TCOed until it isn't. > EDIT: Also, this is the exact opposite of your comment which I replied to. No it isn't. It's the detail of how it happens. If you use Scala at scale with a team that includes non-experts it will happen to you.

lmm 1y ago

Yes, the problem is if you didn't add it but the compiler was still silently TCOing your function, until one day it doesn't.

Quekid5 1y ago
Sure, but if you're relying on the TCO, you kind of have to actually state that, regardless? (At least if you want to avoid accidental regressions.) I don't see any way around having to state your intent (as a programmer) for this. It's just a semantic difference in behavior unless your Abstract Machine allows for just ignoring the possibility of stack overflow entirely.
- lmm 1y ago
  > I don't see any way around having to state your intent (as a programmer) for this. I want a way to state that my intent is to not rely on the TCO. Even a second explicit annotation for "do not TCO this function" would be better than what Scala currently does (but frankly TCO is surprising enough to debug that I think it should be opt-in rather than opt-out).
  - Quekid5 1y ago
    > I want a way to state that my intent is to not rely on the TCO. How would that work? You want a nontail keyword to indicate that intent explicitly? I guess I could imagine a scenario where you want to de-optimize a TCO into a non-TC... but I mean... that's got to be rare enough to just not bother with? EDIT: Also, this is the exact opposite of your comment which I replied to. Make up your mind on what you want and we can maybe find a way to achieve it
    - lmm 1y ago
      > How would that work? You want a nontail keyword to indicate that intent explicitly? Either that, or to not have TCO applied if I don't set a keyword (which I'd prefer). > I guess I could imagine a scenario where you want to de-optimize a TCO into a non-TC... but I mean... that's got to be rare enough to just not bother with? Sometimes I know that a given function will eventually need to be non-TC, in which case I want a way to make it non-TCO now. More commonly a junior team member just hasn't thought about TC-ness at all, in which case I'd rather the function not be TCOed and fail-fast than be TCOed until it isn't. > EDIT: Also, this is the exact opposite of your comment which I replied to. No it isn't. It's the detail of how it happens. If you use Scala at scale with a team that includes non-experts it will happen to you.