I insist, why not support optional garbage collected struct(gc) that can inherit another struct(gc) (which can take advantage of WebAssembly reference types)? I find myself often limited, being unable to express some inheritances. The main use-cases are UI and compiler semantic model Symbol.
The current workaround is making your own personal Any and providing explicit covariant conversion methods to every subtype, however this workaround is unable to inherit fields, thus, when implementing, for example, UI components, you need to reimplement methods such as add_child(...) etc. to some subtypes, due to supertype trait being unable to store fields.
So struct(gc) should at least support:
Inheriting another struct(gc)
Overriding instance method
struct(gc) is only allowed if the runtime garbage collector is allowed. So this would likely require a compiler option, like --use-gc.
These things are all totally unrelated to GC support. Rust doesn't support these things as it favors composition over inheritance. People coming from C++ have often asked for inheritance to be added, for example in Adding true OO capabilities to Rust. We have deliberately avoided adding support for as it generally leads to messier code than when using composition.
I've suggested earlier about Rc in place of Gc, but no one seems to support the idea. I always knew about composition-over-inheritance favour, but I'm in need of inheritance for things like UI (and it's also useful for writting semantic model for language compilers, although I'm not interested on this right now).
Yeah, rust doesn't have the best gui support right now. There are a dozen of crates experimenting with non-inheritance based models. As for an immediate need you probably have, maybe you could do something like gtk-rs does?
Enums should be fine for compiler usage as the set of syntax elements that can occur at any given place is fixed. This is what rustc itself does.