Offensive Security Researcher & Quantum Cryptography Analyst

Enumerating Cases in Rust Programming Language: Enums, Match Expressions, and Option/Result Types

Abdul Wahab Junaid
Enumerating Cases in Rust

When I first started writing Rust, I came from a background where enums were basically glorified integers. You’d get a handful of named constants, maybe a switch statement, and that was it. Rust completely changed how I think about enums, and honestly, this is one of the features that made me fall in love with the language. Rust enums aren’t just labels — they’re a way to model your program’s data so precisely that entire categories of bugs simply can’t compile.

In this article, I want to walk through everything I’ve learned about enums, match expressions, and the two enums that quietly run the entire Rust ecosystem: Option and Result. I’ll go from the absolute basics to the more advanced patterns I use in real projects, and I’ll explain the “why” behind the syntax, not just the “how.”

What Makes Rust Enums Different

In most C-family languages, an enum is a set of named integers. In Rust, an enum is a sum type — it can hold one of several variants, and each variant can carry its own data. This is a big deal because it means I can represent “this OR that OR that” relationships directly in the type system, instead of faking it with flags, null values, or inheritance hierarchies.

Here’s the simplest possible enum:

enum Direction {
    North,
    South,
    East,
    West,
}

Nothing surprising yet. But watch what happens when I let variants carry data:

enum Shape {
    Circle(f64),
    Rectangle(f64, f64),
    Triangle(f64, f64, f64),
}

Each variant of Shape carries different data. Circle needs a radius. Rectangle needs width and height. Triangle needs three side lengths. I don’t need a separate struct for each shape plus a trait to unify them (though I could do that too) — the enum itself is the unifying type.

I can also use named fields, which I personally prefer once a variant has more than one or two pieces of data:

enum WebEvent {
    PageLoad,
    KeyPress { key: char },
    Click { x: i64, y: i64 },
}

Why This Matters for Memory Safety

Under the hood, a Rust enum is stored as a tag (which variant is active) plus enough space to hold the largest variant’s data. This is often called a “tagged union.” The compiler tracks which variant is active at compile time as much as possible, and enforces at runtime (via the tag) which variant you’re actually holding.

This matters for memory safety because it’s impossible to accidentally read a Rectangle‘s data as if it were a Circle. In C, if you misuse a union, you get undefined behavior — you might read garbage memory or misinterpret bytes. In Rust, you can only get at an enum’s data through pattern matching, and the compiler forces you to handle every variant correctly. There’s no way to “forget” which variant you’re looking at.

Match Expressions: The Heart of Rust Control Flow

If enums are how you represent “one of several things,” match is how you handle each possibility. The match expression is exhaustive by default — the compiler will refuse to build your code if you forget a case.

fn describe(shape: &Shape) -> String {
    match shape {
        Shape::Circle(radius) => format!("Circle with radius {radius}"),
        Shape::Rectangle(w, h) => format!("Rectangle {w} x {h}"),
        Shape::Triangle(a, b, c) => format!("Triangle with sides {a}, {b}, {c}"),
    }
}

If I add a new variant to Shape later — say Shape::Square(f64) — and forget to update this match, the code won’t compile. This “exhaustiveness checking” is one of the most valuable features I rely on when refactoring. I don’t need to grep the codebase hoping I found every place that handles shapes; the compiler does it for me.

Match Guards and Bindings

You can add extra conditions to match arms with guards:

fn categorize(n: i32) -> &'static str {
    match n {
        x if x < 0 => "negative",
        0 => "zero",
        x if x % 2 == 0 => "positive even",
        _ => "positive odd",
    }
}

You can also bind a value while matching a range, which I use constantly for things like HTTP status codes:

fn status_category(code: u16) -> &'static str {
    match code {
        100..=199 => "informational",
        200..=299 => "success",
        300..=399 => "redirection",
        400..=499 => "client error",
        500..=599 => "server error",
        _ => "unknown",
    }
}

Destructuring in Match

Match works with structs, tuples, and nested enums too:

struct Point {
    x: i32,
    y: i32,
}

fn describe_point(p: &Point) -> String {
    match p {
        Point { x: 0, y: 0 } => "origin".to_string(),
        Point { x, y: 0 } => format!("on x-axis at {x}"),
        Point { x: 0, y } => format!("on y-axis at {y}"),
        Point { x, y } => format!("at ({x}, {y})"),
    }
}

I find this incredibly expressive. I’m not writing a chain of if statements checking p.x == 0 && p.y == 0 — I’m describing the shape of the data I care about, and letting the compiler figure out the branching.

if let and while let

Sometimes I only care about one variant and want to ignore the rest. That’s when I reach for if let:

let maybe_number: Option<i32> = Some(7);

if let Some(n) = maybe_number {
    println!("Got a number: {n}");
} else {
    println!("No number here");
}

while let is the loop version, useful when draining a stack or queue:

let mut stack = vec![1, 2, 3];

while let Some(top) = stack.pop() {
    println!("{top}");
}

The Option Type: Rust’s Answer to Null

This is where enums stop being a neat syntax trick and start actively preventing bugs. Rust has no null. Instead, the standard library defines:

enum Option<T> {
    Some(T),
    None,
}

Any value that might be absent is wrapped in Option<T>. The compiler will not let you use the inner value without first checking whether it’s Some or None. This eliminates the entire class of null pointer exceptions that plague languages with native null.

fn find_user(id: u32) -> Option<String> {
    if id == 1 {
        Some("Ahmad".to_string())
    } else {
        None
    }
}

fn main() {
    match find_user(1) {
        Some(name) => println!("Found user: {name}"),
        None => println!("No user found"),
    }
}

Output:

Found user: Ahmad

Option comes with a rich set of combinator methods I use daily instead of manual matching:

let name = find_user(2).unwrap_or_else(|| "Guest".to_string());
let upper = find_user(1).map(|n| n.to_uppercase());
let has_user = find_user(1).is_some();

unwrap() panics if the value is None, which is fine for prototyping but something I avoid in production code unless I’ve already proven the value can’t be None.

The Result Type: Explicit, Recoverable Errors

Result is Option‘s sibling for operations that can fail with a specific error, not just be absent:

enum Result<T, E> {
    Ok(T),
    Err(E),
}

Here’s a function that parses a string into a number, using Result to communicate success or failure explicitly:

fn parse_age(input: &str) -> Result<u8, String> {
    match input.trim().parse::<u8>() {
        Ok(age) => Ok(age),
        Err(_) => Err(format!("'{input}' is not a valid age")),
    }
}

fn main() {
    match parse_age("25") {
        Ok(age) => println!("Age is {age}"),
        Err(e) => println!("Error: {e}"),
    }
}

The ? Operator

Writing match for every fallible operation gets verbose fast. The ? operator propagates errors automatically:

use std::num::ParseIntError;

fn double_input(input: &str) -> Result<i32, ParseIntError> {
    let n: i32 = input.trim().parse()?;
    Ok(n * 2)
}

If parse() fails, ? returns the Err immediately from double_input. If it succeeds, execution continues with the unwrapped value. This is idiomatic Rust — I use ? in nearly every function that can fail, and it keeps the “happy path” readable while still forcing error handling to exist.

For custom errors across a whole application, I usually reach for the thiserror crate to define error enums, or anyhow for quick prototyping where I don’t need precise error types.

Real-World Applications

I’ve used enums plus match for:

Best Practices I Follow

Common Mistakes and Debugging Tips

One mistake I made early on was overusing _ => {} catch-all arms in match, which quietly defeats exhaustiveness checking. If I add a new variant later, the catch-all silently swallows it instead of forcing me to handle it. I now only use _ when I genuinely mean “everything else, on purpose.”

Another common trap is calling .unwrap() on a Result from something like file I/O and getting a confusing panic message. Using .expect("failed to read config file") instead gives you a much clearer message when things go wrong, which saves debugging time.

If you’re getting a “non-exhaustive patterns” compiler error, that’s actually good news — the compiler just caught a case you forgot to handle before it became a runtime bug.

Frequently Asked Questions

Is Rust’s Option the same as nullable types in other languages? Conceptually similar, but structurally different. Option<T> is a real enum you must unwrap explicitly; there’s no implicit conversion, so you can’t accidentally treat a None as a valid value.

When should I use Result instead of Option? Use Option when a value can be legitimately absent with no explanation needed. Use Result when an operation can fail and you want to communicate why.

Does using enums and match hurt performance? No — match on an enum typically compiles down to a jump table or a simple comparison, and Rust’s zero-cost abstractions mean this pattern matching has effectively no runtime overhead compared to hand-written branching.

Can enums implement traits and methods? Yes. You can write impl blocks for enums exactly like structs, including implementing standard traits like Display, Debug, or your own custom traits.

Summary

Rust enums, combined with match, Option, and Result, form the backbone of how the language handles branching logic and error handling. Instead of relying on null references or exception-based control flow, Rust makes every possible case explicit and forces you to handle it at compile time. Once this clicked for me, I started designing my data structures around “what are all the valid states this can be in” rather than bolting validation on afterward — and my code got noticeably more reliable for it.

References

Exit mobile version