What would it take to revive Enum Variant Types?

There was an issue from some time ago: Enum Variant Types · Issue #122 · rust-lang/lang-team · GitHub

I've been noticing how this could improve the code I've been working on lately and I'd be willing to move it forward.


I want this too, but I don't think now is the right time to revive the feature quite yet, for the following reason.

Enum variant types, where any value of an enum type that matches a specific variant is a member of a subtype corresponding to that variant, are a special case of a more general feature, where any value of a type that matches a specific pattern is a member of a subtype corresponding to that pattern. The more general feature would also encompass ranged integers, among other things.

But "types that depend on patterns" requires the details of pattern matching to be settled and specified, and there is still a lot of active work in that area (important keywords are "structural equality" and "valtrees"). I recently proposed an RFC that would have affected pattern matching, and it was closed in part because of the potential to conflict with these in-progress changes. So it's probably best to wait until the outstanding questions are resolved, before writing a detailed proposal for this feature.


I think the place to start thinking about enum variant types would be the new types team, https://github.com/rust-lang/rfcs/pull/3254.

As far as I know there's lots of interest in the general idea, but the details of exactly when things should get the variant type are highly nuanced, especially when back-compat comes into the picture. (Where do coercions happen from the variant type to the enum type, for example? Or are they something other than coercions? Does this need custom new rules for returning different variants in different match arms? What does it mean to implement Copy for only some variant types? …)

It's also possible that, practically, it'll need rustc to move to the new type/trait solver before it can be implemented.