Enumerations with Data

A struct groups fields that appear together. An enum models a value that is one of several shapes — and Rust's enums are full algebraic data types, not the integer aliases that C and older languages offer. The standard example from the documentation is worth typing out yourself:

enum IpAddr {
    V4(u8, u8, u8, u8),
    V6(String),
}

let home = IpAddr::V4(127, 0, 0, 1);
let loopback = IpAddr::V6(String::from("::1"));

Each variant is a namespaced constructor: V4 and V6 live under IpAddr, so writing bare V4(127, 0, 0, 1) is an error — you always qualify with the enum name. This is why Some(5) reads the way it does: Some is a variant of the Option<T> enum, and the call constructs an Option<i32> holding the value 5. Once you internalize that Some is just a constructor path, Option and Result stop being special cases and become ordinary enums you already know how to use.

Payload flexibility is the headline feature. Different variants may hold different types — tuples, structs, references, other enums, or nothing at all:

enum Event<'a> {
    Connected { peer: &'a str },   // named fields, like a struct variant
    Data(Vec<u8>),                 // tuple variant
    Disconnect(u8),                // single-value tuple variant
    Ping,                          // unit variant: no payload
}

Struct variants (Connected { peer }) are the same idea as named-field structs, and every method you will write on enums treats them that way. Because variants are constructors, they work in pattern position too — Event::Data(bytes) both builds a value (expression) and describes one (pattern), which is the symmetry that makes match Expressions feel natural.

Enums take #[derive(...)] and impl blocks exactly like structs:

#[derive(Debug, Clone, PartialEq)]
enum Status { Ready, Degraded(u8), Down }

impl Status {
    fn is_healthy(&self) -> bool {
        matches!(self, Status::Ready)
    }
}

assert!(!Status::Degraded(3).is_healthy());

matches! is a macro built on patterns that answers "does this value match the shape?" without binding anything — handy in conditions before you learn full pattern syntax. One naming convention to adopt immediately: enum type names are singular (Status, not Statuses) and variant names describe states or events (Ready, Data), because you will write Status::Ready at every use site.

The real payoff shows up when states interact. Consider an order lifecycle that would sprawl across four booleans in a looser language:

enum Payment { Pending, Charged { txn: String }, Refunded(String) }
enum Shipment { NotShipped, Packed, Shipped { tracking: String }, Delivered }

struct Order<'a> {
    id: &'a str,
    payment: Payment,
    shipment: Shipment,
}

impl Order<'_> {
    fn can_cancel(&self) -> bool {
        matches!(self.payment, Payment::Pending)
            && matches!(self.shipment, Shipment::NotShipped | Shipment::Packed)
    }
}

Enums nest naturally — Order holds two enums, and each enum's payload could hold another — so the type system mirrors the domain's structure instead of documenting it in comments. Impossible combinations become unrepresentable: there is no ChargeRefundedButNeverCharged state, because Payment admits exactly the variants you declared. That property, making illegal states unrepresentable, is the phrase interviewers listen for when they ask why you would reach for an enum over a pile of bools and Options.

Heterogeneous collections follow the same logic: a Vec<Event> holds Ping and Data(..) values side by side because they share one type, which is exactly how event loops, protocol parsers, and UI message queues are built in real Rust codebases.

An enum value must hold any of its variants, so its size is the size of the largest variant plus enough room to record which variant is active. That record is the discriminant — an integer tag the compiler stores alongside the payload and checks during pattern matching.

enum Message {
    Quit,                        // no payload
    Move { x: i32, y: i32 },     // 8 bytes of payload
    Write(String),               // a String: 24 bytes on 64-bit
}

assert_eq!(std::mem::size_of::<Message>(), 32); // payload 24 + tag 8, aligned

The number is not something to memorize — it is something to measure with size_of when layout matters — but the model is: largest variant, plus tag, rounded for alignment. For network protocols, FFI, or #[repr(C)] structs you can pin the tag down with #[repr(u8)] on the enum, which makes the layout a documented contract instead of a compiler choice.

The tag is also where Rust's standard library hides an optimization you use without knowing it. Many types have invalid bit patterns the compiler can borrow as the tag — references can never be null, Box is never null, NonZeroU32 is never zero — so Option<T> can store its None marker inside the unused pattern of T:

assert_eq!(std::mem::size_of::<Option<u8>>(), 2);        // tag needed: u8 has no spare pattern
assert_eq!(std::mem::size_of::<Option<&u64>>(), 8);      // null doubles as None: free
assert_eq!(std::mem::size_of::<Option<Box<u64>>>(), 8);  // same trick with Box

This is the niche optimization, and it explains why idiomatic Rust can afford Option everywhere: for references, pointers, and NonZero* integers, wrapping in Option costs zero bytes. It also explains the occasional surprise — Option<MyBigEnum> may add only one byte if the big enum itself has a spare discriminant, while Option<(u8, u8)> costs a third byte on top of the pair.

Three places where the layout stops being an implementation detail. FFI and interop: passing an enum to C code needs a declared layout, so #[repr(u8)] or #[repr(C)] turns "whatever the compiler chose" into a contract your C header can match. Serialization: formats like bincode mirror in-memory layout, so a #[repr] decision becomes a wire-format decision — pin it deliberately or use a real serializer that does not depend on layout. Memory-heavy containers: a million-element Vec of a fat enum pays the largest variant for every element, even the unit variants. If one variant is enormous and rare, box it:

enum Record {
    Tiny(u16),
    Huge(Box<BigPayload>),   // 8 bytes instead of sizeof::<BigPayload>
}

The Box costs one allocation only when Huge is constructed, and every Record shrinks to tag-plus-payload size.

One more distinction worth having ready: discriminant versus equality. mem::discriminant(&v) compares only which variant is active, ignoring the payload, while derived PartialEq compares payload values too:

let a = Record::Tiny(7);
let b = Record::Tiny(9);
assert_ne!(a, b);                          // payloads differ, so the values differ
assert!(std::mem::discriminant(&a) == std::mem::discriminant(&b)); // same variant

Derived equality is safe around padding — the compiler compares fields, not raw bytes — so enums can be #[derive(PartialEq, Eq, Hash)] and used as HashMap keys without any of the stale-padding hazards that raw byte comparison would bring.

For interviewers, the take-away sentence is: "an enum packs its largest variant with a discriminant, and the compiler reuses unused bit patterns as that discriminant whenever possible, so Option<&T> is pointer-sized." Add that layout is observable with size_of and controllable with repr, and you have covered the question.

An enum with no payloads is just a set of named discriminants — the familiar C enum — and Rust gives it integer semantics you can use deliberately:

#[repr(u8)]
enum Opcode {
    Nop = 0,
    Read = 1,
    Write = 2,
    Seek = 10,
}

assert_eq!(Opcode::Seek as u8, 10);
assert_eq!(std::mem::discriminant(&Opcode::Read), std::mem::discriminant(&Opcode::Read));

Without explicit values, discriminants start at 0 and increment per variant. The as cast to an integer works only for data-free enums, and the #[repr(u8)] locks the exact encoding — the combination is what makes plain enums usable for wire protocols, opcode tables, and array indexing:

const TABLE: [&str; 3] = ["nop", "read", "write"];
let op = Opcode::Read;
println!("{}", TABLE[op as usize]);       // discriminant as an index

That pattern — enum for the programmer, integer on the wire, as to convert — is the idiomatic replacement for #define-style constants, and it is strictly better: the type system still knows the set of valid values inside your code.

The reverse direction is where caution is required. Casting an integer back to an enum with as is accepted for data-free enums, but it never validates the value, and the result is unspecified when the number is not a declared discriminant:

let op = 7u8 as Opcode;   // compiles — and `op` is now an Opcode that was never declared

For anything crossing a trust boundary — a byte from a socket, a field from a file — use the checked conversion instead:

use std::convert::TryFrom;

let op = Opcode::try_from(2u8);            // Result<Opcode, TryFromIntError>
assert!(matches!(op, Ok(Opcode::Write)));
assert!(Opcode::try_from(7u8).is_err());   // rejected loudly, at the edge

The rule to carry into production code: convert at the boundary with try_from, work with the enum internally, and convert out with as when you control the value. That way no unchecked integer ever reaches a match arm, and — as the next topic covers — the exhaustiveness checker protects every path the enum can take.

Two follow-on patterns round out the C-like corner. Bit sets combine discriminants with shifts, and validation still belongs at the edge:

#[repr(u8)]
#[derive(Clone, Copy, PartialEq)]
enum Permission { Read = 1, Write = 2, Execute = 4 }

fn parse(bits: u8) -> Vec<Permission> {
    [Permission::Read, Permission::Write, Permission::Execute]
        .into_iter()
        .filter(|p| bits & (*p as u8) != 0)
        .collect()
}

Here the enum doubles as documentation for each bit's meaning, while the raw u8 carries the combination — a common shape for flag words in file formats and config values. Explicit discriminants also exist for enums with payloads (stable since Rust 1.66, and they require a primitive representation such as #[repr(u8)]), which is how on-disk record tags stay stable while payloads evolve.

That last point deserves emphasis, because it is a design question, not a syntax one: variants are a public contract. Adding a variant to a public enum breaks every downstream match that relied on exhaustiveness, which is precisely why the compiler's non-exhaustiveness checking is a feature rather than an obstacle — and why the standard library marks evolving types #[non_exhaustive], forcing downstream code to include a wildcard arm from day one. When you design an enum that leaves your crate, decide deliberately whether callers may rely on handling exactly today's variants, or whether you are reserving the right to grow.