# What would it take to revive Enum Variant Types?

**URL:** https://internals.rust-lang.org/t/what-would-it-take-to-revive-enum-variant-types/17466
**Category:** language design
**Created:** [September 29, 2022, 6:25am UTC](https://internals.rust-lang.org/t/what-would-it-take-to-revive-enum-variant-types/17466 "2022-09-29T06:25:01Z")
**Posts on this page:** 1
**Showing post:** 2

<div class="post-metadata">

### Author: ![Jules-Bertholet](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jules-bertholet/32/10671_2.png) [@Jules-Bertholet](https://internals.rust-lang.org/u/Jules-Bertholet)
#### Post date: [September 29, 2022, 1:55pm UTC](https://internals.rust-lang.org/t/what-would-it-take-to-revive-enum-variant-types/17466/2 "2022-09-29T13:55:57Z")

</div>

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.

---

_[View the full topic](https://internals.rust-lang.org/t/what-would-it-take-to-revive-enum-variant-types/17466)._