How to Create Enums With Constant Values in Rust

By the end of this page, you will understand why Rust does not allow enum variants like A(123) and B(456), and what to use instead. You will learn the difference between enum payloads and enum discriminants, how to attach fixed meanings to variants, and several practical Rust patterns for working with constant values in enums.

Rust enums can represent one of several possible variants. Each variant can optionally carry data.

For example:

enum MyEnum {
    A(i32),
    B(i32),
}

This does not mean that A always contains one specific number. It means:

• A can store any i32 value
• B can store any i32 value

So values like these are valid:

let x = MyEnum::A(123);
let y = MyEnum::A(999);
let z = MyEnum::B(456);

When you write A(i32), you are declaring the type of data that the variant can hold, not a fixed constant.

Think of an enum like a set of labeled cards.

• A(i32) means: the A card has a pocket that can hold any i32
• A by itself means: the A card is just a label

If you want each label to stand for a fixed number, do not try to put the number inside the type definition as a literal. Instead, keep the labels simple and use a lookup rule:

• A maps to 123
• B maps to 456

So the enum is the name, and a method or match is the legend that tells you what each name means.

1. Enum with associated data

Use this when each instance may carry a different value:

enum MyEnum {
    A(i32),
    B(i32),
}

fn main() {
    let x = MyEnum::A(123);
    let y = MyEnum::B(456);
}

Here, 123 and 456 are runtime values stored inside the enum variants.

2. Enum with fixed meanings

Use plain variants and map them to constants:

enum MyEnum {
    A,
    B,
}

impl MyEnum {
    fn value(self) -> i32 {
        match self {
            MyEnum::A => 123,
            MyEnum::B => 456,
        }
    }
}

fn () {
      = MyEnum::A;
    (, a.()); 
}

Consider this example:

enum MyEnum {
    A,
    B,
}

impl MyEnum {
    fn value(self) -> i32 {
        match self {
            MyEnum::A => 123,
            MyEnum::B => 456,
        }
    }
}

fn main() {
    let item = MyEnum::B;
    let number = item.value();
    println!("{}", number);
}

Step-by-step

1. enum MyEnum { A, B }

   • Defines two possible variants.
   • Neither variant stores extra data.

2. impl MyEnum { fn value(self) -> i32 { ... } }

   • Adds a method named value.
   • The method returns an i32 based on the variant.

3. let item = MyEnum::B;

Status and code mappings

Enums often represent named states that correspond to fixed codes:

enum HttpStatusKind {
    Ok,
    NotFound,
    ServerError,
}

impl HttpStatusKind {
    fn code(self) -> u16 {
        match self {
            HttpStatusKind::Ok => 200,
            HttpStatusKind::NotFound => 404,
            HttpStatusKind::ServerError => 500,
        }
    }
}

Protocol or message types

A network protocol may use symbolic names in code but fixed numeric values on the wire.

enum MessageType {
    Connect,
    Disconnect,
}

impl MessageType {
    fn id(self) -> u8 {
        match self {
            MessageType::Connect => 1,
            MessageType::Disconnect => 2,
        }
    }
}

Configuration modes

An app might use variants for readable logic and methods for fixed settings.

In real Rust projects, developers usually choose one of these patterns depending on intent.

1. Fieldless enum + method

This is the most common when you want readable variants and fixed derived values.

enum LogLevel {
    Debug,
    Info,
    Error,
}

impl LogLevel {
    fn priority(self) -> u8 {
        match self {
            LogLevel::Debug => 10,
            LogLevel::Info => 20,
            LogLevel::Error => 30,
        }
    }
}

Why it is common:

• easy to read
• easy to extend
• works well with match
• avoids scattered magic numbers

2. Validation and conversion methods

Enums often expose helper methods like as_code, to_id, or from_code.

enum Role {
    Admin,
    User,
}

impl  {
     ()   {
          {
            Role::Admin => ,
            Role::User => ,
        }
    }

     (code: )  <> {
         code {
             => (Role::Admin),
             => (Role::User),
            _ => ,
        }
    }
}

Mistake 1: Treating tuple variant fields as fixed values

Broken code:

enum MyEnum {
    A(123),
    B(456),
}

Why it fails:

• Rust expects a type like i32, not a literal like 123.

Fix:

enum MyEnum {
    A,
    B,
}

impl MyEnum {
    fn value(self) -> i32 {
        match self {
            MyEnum::A => 123,
            MyEnum::B => 456,
        }
    }
}

Mistake 2: Using associated data when no variable data is needed

Less ideal:

enum MyEnum {
    A(i32),
    B(),
}

  = MyEnum::();

// Variable data per variant
enum MyEnum {
    A(i32),
    B(i32),
}

// Fixed meaning per variant
enum MyEnum2 {
    A,
    B,
}

impl MyEnum2 {
    fn value(self) -> i32 {
        match self {
            MyEnum2::A => 123,
            MyEnum2::B => 456,
        }
    }
}

// Explicit discriminants for fieldless enums
enum MyEnum3 {
    A = 123,
    B = 456,
}

Rules to remember

• A(i32) means A carries a value of type i32
• A(123) is invalid in an enum definition because 123 is a value, not a type
• Use A = 123 only for fieldless enums
• Use a method like value() when variants should map to fixed constants

Can I write A(123) directly inside a Rust enum definition?

No. Inside A(...) in an enum definition, Rust expects a type, not a literal value.

How do I give each enum variant a fixed integer in Rust?

Use a fieldless enum with explicit discriminants:

enum MyEnum {
    A = 123,
    B = 456,
}

Or use a method that returns the desired value.

What is the difference between A(i32) and A = 123?

• A(i32) means the variant stores an i32
• A = 123 means the variant has discriminant value 123

These are different concepts.

When should I use a method instead of discriminants?

Use a method when you want a readable mapping, extra flexibility, or values that may later depend on more logic.

Are enum discriminants only for fieldless enums?

Yes, explicit discriminants are used with fieldless enums in the normal C-like style.

Is using constants instead of enums okay?

Yes, if you only need named values. But if the values represent a closed set of choices, enums are usually safer and clearer.

• Rust enums — the main concept for representing one value out of several variants.
• Pattern matching — commonly used with enums to handle each variant.
• Associated data in enums — important for understanding Variant(Type) syntax.
• Discriminants — explains how fieldless enum variants can have explicit numeric values.
• Associated constants — useful when you need named constant values without enum behavior.
• match expressions — the standard way to map enum variants to values.
• Structs in Rust — useful for comparing enums with data-carrying types.
• #[repr(...)] in Rust — relevant when enum integer representation matters for interop.