Match with enums in Rust - Time & Space Complexity

Time Complexity: Match with enums

O(n)

Understanding Time Complexity

We want to understand how the time it takes to run a match statement with enums changes as we add more enum variants.

How does the number of enum cases affect the work done during matching?

Scenario Under Consideration

Analyze the time complexity of the following code snippet.

enum Color {
    Red,
    Green,
    Blue,
    Yellow,
}

fn describe_color(color: Color) -> &'static str {
    match color {
        Color::Red => "Red",
        Color::Green => "Green",
        Color::Blue => "Blue",
        Color::Yellow => "Yellow",
    }
}
    

This code matches an enum value to return a string describing the color.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: The match statement checks the enum variant.
• How many times: It checks once per call, but internally it may compare against each variant until it finds a match.

How Execution Grows With Input

As the number of enum variants grows, the match may need to check more cases before finding the right one.

Number of Variants (n)	Approx. Checks
4	Up to 4 checks
10	Up to 10 checks
100	Up to 100 checks

Pattern observation: The number of checks grows roughly in a straight line with the number of variants.

Final Time Complexity

Time Complexity: O(n)

This means the time to find the matching enum variant grows linearly with the number of variants.

Common Mistake

[X] Wrong: "Matching an enum is always constant time because it's just one check."

[OK] Correct: The match may check multiple variants one by one until it finds a match, so more variants can mean more checks.

Interview Connect

Understanding how matching enums scales helps you reason about code efficiency and choose the right data structures in real projects.

Self-Check

"What if we used a hash map to store enum variant data instead of match? How would the time complexity change?"

Practice

1.

What does the match statement do when used with enums in Rust?

easy

A. It checks the enum variant and runs the matching code block.

B. It converts the enum into a string automatically.

C. It creates a new enum variant.

D. It deletes the enum variant from memory.

Solution

1. Step 1: Understand the purpose of match with enums

   The match statement compares the enum value against each variant.

2. Step 2: Identify what happens on a match

   When a variant matches, the corresponding code block runs.

3. Final Answer:

   It checks the enum variant and runs the matching code block. -> Option A

4. Quick Check:

   Match runs code by enum variant [OK]

Hint: Match arms correspond to enum variants directly [OK]

Common Mistakes:

• Thinking match converts enums to strings
• Assuming match creates or deletes variants
• Confusing match with if-else statements

2.

Which of the following is the correct syntax to match an enum Color with variants Red, Green, and Blue?

enum Color { Red, Green, Blue }

easy

A. match color { Color.Red => {}, Color.Green => {}, Color.Blue => {} }

B. match color { Red => {}, Green => {}, Blue => {} }

C. match color { Color::Red => {}, Color::Green => {}, Color::Blue => {} }

D. match color { 'Red' => {}, 'Green' => {}, 'Blue' => {} }

Solution

1. Step 1: Recall enum variant syntax in match

   Enum variants must be prefixed with the enum name and double colon, like Color::Red.

2. Step 2: Check each option's syntax

   Only match color { Color::Red => {}, Color::Green => {}, Color::Blue => {} } uses the correct Color::Variant syntax.

3. Final Answer:

   match color { Color::Red => {}, Color::Green => {}, Color::Blue => {} } -> Option C

4. Quick Check:

   Enum variants use EnumName::Variant [OK]

Hint: Use EnumName::Variant in match arms [OK]

Common Mistakes:

• Omitting enum name prefix
• Using dot instead of double colon
• Using strings instead of variants

3.

What will be the output of this Rust code?

enum Direction { North, South, East, West }

fn main() {
    let dir = Direction::East;
    let message = match dir {
        Direction::North => "Going up",
        Direction::South => "Going down",
        Direction::East => "Going right",
        Direction::West => "Going left",
    };
    println!("{}", message);
}

medium

A. Going right

B. Going up

C. Going left

D. Going down

Solution

1. Step 1: Identify the enum variant assigned

   The variable dir is set to Direction::East.

2. Step 2: Match dir to the correct message

   The match arm for Direction::East returns "Going right".

3. Final Answer:

   Going right -> Option A

4. Quick Check:

   Direction::East matches "Going right" [OK]

Hint: Match returns value for the exact enum variant [OK]

Common Mistakes:

• Mixing up enum variants and their messages
• Forgetting to use EnumName::Variant in match
• Assuming default or fallback arm runs

4.

Find the error in this Rust code snippet using match with enums:

enum Status { Success, Failure }

fn check(status: Status) {
    match status {
        Status::Success => println!("Success"),
        // Missing Failure arm
    }
}

medium

A. Missing semicolon after println! macro

B. Function check should return a value

C. Incorrect enum variant syntax

D. Missing match arm for Status::Failure

Solution

1. Step 1: Check completeness of match arms

   The match statement covers Status::Success but misses Status::Failure.

2. Step 2: Understand Rust's exhaustiveness requirement

   Rust requires all enum variants to be matched or a catch-all arm (_) to avoid compile errors.

3. Final Answer:

   Missing match arm for Status::Failure -> Option D

4. Quick Check:

   All enum variants must be matched [OK]

Hint: Match must cover all enum variants or use _ arm [OK]

Common Mistakes:

• Leaving out enum variants in match arms
• Assuming partial match compiles
• Confusing semicolon placement with match completeness

5.

Given this enum with data:

enum Message {
    Quit,
    Move { x: i32, y: i32 },
    Write(String),
    ChangeColor(i32, i32, i32),
}

Which match arm correctly extracts the x and y values from Message::Move?

hard

A. Message::Move(x, y) => println!("x: {}, y: {}", x, y),

B. Message::Move { x, y } => println!("x: {}, y: {}", x, y),

C. Message::Move(x: x, y: y) => println!("x: {}, y: {}", x, y),

D. Message::Move(x: x, y) => println!("x: {}, y: {}", x, y),

Solution

1. Step 1: Identify the enum variant with named fields

   Move uses named fields { x: i32, y: i32 }.

2. Step 2: Match syntax for named fields

   Use Message::Move { x, y } to destructure named fields directly.

3. Final Answer:

   Message::Move { x, y } => println!("x: {}, y: {}", x, y), -> Option B

4. Quick Check:

   Named fields use braces and field names [OK]

Hint: Use braces and field names to destructure named fields [OK]

Common Mistakes:

• Using tuple pattern for struct-like variant
• Mixing colon syntax incorrectly
• Omitting braces for named fields