The issue used to be with LLVM, yes, but that appears to be solved (see Clang's 'musttail' attribute). Instead it's more about language design. Constructors, destructors, and all of the fancy language features Rust has must work with this new feature, with no changes being visible elsewhere.
I had no idea about that. Is there a specific reason why that choice was made?
WASM doesn't support guaranteed TCE yet (it's a proposal), and that's an important target for Rust.
Goto has been iirc a point of discussion from the language design pov for Rust. I don't think it promotes good design for most applications but ymmv.
Performance, although this possibly depends on your compiler, whether you use PGO, and similar finicky issues.
Example: https://eli.thegreenplace.net/2012/07/12/computed-goto-for-e...
Some prior HN discussion: https://news.ycombinator.com/item?id=18678920
Another example where goto is relevant is implementing finite automata. A (very short) paper from 1988 that discusses three different ways of implementing a finite state machine is "How (Not) to Code a Finite State Machine". The documentation of RE2C may be even more interesting: https://re2c.org
RE2C is a program that compiles finite automata into C, Go, or Rust code. It provides many implementation strategies: it can make use of computed or labelled gotos when the language provides them.
Implementing pushdown automata comes with similar issues.
I suspect if you could use UNION better and be the same as Enum in Rust you could do us a favor! Also I wish I could do this easily:
enum Tag {
Int,
Bool
}
enum Data {
Int(Vec<i32>),
Bool(Vec<bool>)
}
struct Val {
tag:Tag,
data:Data
}
let n = val.as_i32::<Tag::Int>(&self) -> Vec<i32> outer: loop {
loop {
let res = self.interpreter_loop(…);
match res {
Continue => {}
Return => { break 'outer; }
Exception => { break; }
}
}