Skip to content

Tracking Issue for Unnamed Enum Variants (Open Enums) #156628

@kupiakos

Description

@kupiakos

This is the tracking issue for RFC 3894 - "Open up your enum with an unnamed variant". It was informally 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?

Implementation history

Coming soon to a PR near you!

Metadata

Metadata

Assignees

No one assigned

    Labels

    B-experimentalBlocker: In-tree experiment; RFC pending, not yet approved or unneeded (requires FCP to stabilize).C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCF-unnamed_enum_variants`#![feature(unnamed_enum_variants)]`I-lang-nominatedNominated for discussion during a lang team meeting.S-tracking-unimplementedStatus: The feature has not been implemented.T-langRelevant to the language team

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions