Tracking Issue for Unnamed Enum Variants (Open Enums)

This is the tracking issue for RFC 3894 - "Open up your enum with an unnamed variant". It was approved as a lang experiment in the 2026-04-22 design meeting, and has an associated 2026 project goal. @joshtriplett is the lang-team champion for the experiment.

The feature gate for the issue is #![feature(unnamed_enum_variants)].

CC @rust-lang/lang, @rust-lang/lang-advisors

Motivation for the experiment

While repr allows for a stable ABI for a field-less enum, there's no good way for an enum to declare itself as future-compatible with discriminants that may be assigned to variants in the future. The most notable case for this is FFI with a C enum.

bindgen avoids generating repr(C) enum to interoperate with a C enum by default because C enums are "open" - it is valid to cast an integer that isn't associated with a named value to an enum type. By contrast, Rust enums are "closed": the user always declares every valid value. There is no invalid bit pattern for a C enum but for a Rust enum, anything undeclared is invalid.

Its current solutions to soundly interoperate with a C enum are less ergonomic to use than if we could use a Rust enum soundly.

Proposed Solution

This lang experiment proposes to allow unnamed variants to claim discriminants as valid for an enum ahead-of-time. The below is an open enum and may be cast from u8:

#[repr(u8)] // or other `Int` or `repr(C)`
enum Color {
    Red = 0,
    Green = 1,
    _ = ..,  // All other discriminants in `u8` are assigned to unnamed variants
}
assert!(matches!(0 as Color, Color::Red));
assert!(!matches!(2 as Color, Color::Red | Color::Green));

This uses the Rust closed-enum syntax to declare all valid discriminants up-front, and thus functions as an open enum with the backing integer. This benefits projects that work with many open enums, such as Rust for Linux.

Further background and motivation is provided in the RFC and project goal. The goal of this lang experiment is to determine:

• Is RFC 3894 tenable to implement in its entirety?
• Should the feature be split or simplified? (e.g. should as casting from integer be a separate feature?)
• Are there edge cases not considered in the RFC that are found during the experiment, such as in MIR lowering?

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

Steps

• Implement the RFC as a lang experiment in nightly
  • Parse unnamed variant syntax and define incomplete feature
  • Unnamed variants on repr(Int) enum with singular discriminants
  • Unnamed variants on repr(Int) enum
  • Unnamed variants including repr(C) enum
  • as cast from Int for open enums
  • Extend core (mem::discriminant, derive(Debug)) to support unnamed variants
  • Ensure Miri allows unnamed enums variants with ranges of discriminants
  • Introduce new lints
• Experiment with nightly implementation, gather feedback, then adjust the RFC as necessary
• Merge the RFC
• Mark the feature as unstable but complete
• Adjust documentation (see instructions on rustc-dev-guide)
• Style updates for unnamed variants (nightly-style-procedure)
  • Style team decision on new formatting
  • Formatting for new syntax has been added to the Style Guide
  • (non-blocking) Formatting has been implemented in rustfmt
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

• Is the Control Flow Integrity encoding of types the only blocker for repr(Int) enum to be ABI compatible with Int?
• What exactly is the best syntax for declaring these?

Implementation history

• #157274
• rust-lang/rust-analyzer#22512

Start by reading RFC 3894 and the linked 2026 project goal, then review the checklist and implementation history, including #157274 and rust-lang/rust-analyzer#22512. This is a multi-stage tracking issue with unresolved syntax and ABI questions; completion requires implementing and evaluating the experiment, updating documentation and style support, and eventually completing stabilization.