Hacker News Reader

Comment by jmalicki | Hacker News Reader

> because it means subtle changes (introducing a destructor, re-ordering code, etc) can change semantics without you realizing it.

No, it won't change semantics - if you say @musttail or similar, it will simply fail to compile if you, say, introduce a destructor - the semantics will not subtly change.

View on HN

Incorrect. `become` does change drop order - https://play.rust-lang.org/?version=nightly&mode=debug&editi....

That's not implementing tail calls breaks things, that's bad design of implementing tail calls breaking things.

The whole idea of "let's change semantics to make it easier" is dumb.

If you want guaranteed tail calls, change your code until it works.

Uh, yes, if you guarantee the semantics only when the code explicitly opts in and not by default then semantics will not subtly change, that is the point of my comment

It's not a change in semantics of compiled code. It is only a change of whether or not the code will compile.

Guaranteeing an optimization that otherwise only might run is a change in semantics. The attribute doesn't allow (in any sensible language) the code to simply not compile because the optimizer doesn't feel like it today (or you compiled with -O0), it forces the compiler to not allocate a stack frame wherever the code fits the structure that makes that definitely possible and fails to compile wherever it doesn't (even if after other optimization passes it happens to fit a structure that makes it possible).

Reply on news.ycombinator.com