This would actually take more work, as there would have to be compiler groundwork to have some way of corresponding names to type as read off from the type, along with associated syntax bikeshedding, and to go back and look variants up when the variant names come back up.
Doh!
This is an interesting example of communication issue; I’ve been arguing for a minimal language impact, while you were championing a minimal compiler impact. No wonder we were talking past each other. It may be worth clarifying which kind of minimalism was referred to; maybe both?
I can sympathize with the compiler impact argument, but ultimately the compiler is pretty malleable whereas any feature introduced in the language is there to stay.
This is why I am loathe introducing two features simultaneously – anonymous enums and anonymous variants – and would rather that each feature be introduced separately and under different feature flags. From a language perspective, I find the usefulness of anonymous enums much more obvious than the usefulness of anonymous variants:
- we already have a variety of anonymous types: voldemort ones (functions, closures) as well as anonymous ones (
impl Trait).
- we only have anonymous fields in tuples, the closest equivalent to anonymous variants.
Especially in case of error-handling, the usecase of this proposal, I would argue that if one has to handle one (or some) case(s) specifically, one better be sure of exactly which case is which. A named variant makes it less error-prone, and less brittle in case of refactoring, and error-handling is really where robustness shines.
