3 ms·
> because it means subtle changes (introducing a destructor, re-ordering code, etc) can change semantics without you realizing it. No, it won't change semantic
by jmalicki 18d ago
> 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.
- gpm 18d agoUh, 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
- jmalicki 18d agoIt's not a change in semantics of compiled code. It is only a change of whether or not the code will compile.
- gpm 18d agoGuaranteeing 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).
- afdbcreid 18d agoIncorrect. `become` does change drop order - https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=fc0fccce5f43ff4605e08b351e4d98a9 https://play.rust-lang.org/?version=nightly&mode=debug&editi....
- jmalicki 18d agoThat'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.