> 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.

▲

afdbcreid 2 hours ago | parent | next [-]

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

	▲	jmalicki an hour ago \| parent [-]
		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.

▲

gpm 3 hours ago | parent | prev [-]

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

	▲	jmalicki 3 hours ago \| parent [-]
		It's not a change in semantics of compiled code. It is only a change of whether or not the code will compile.