Enums with data in Rust - Time & Space Complexity

Time Complexity: Enums with data

O(n)

Understanding Time Complexity

When using enums with data in Rust, it's important to understand how the program's work grows as the input changes.

We want to see how the time to handle enum data changes when we process many enum values.

Scenario Under Consideration

Analyze the time complexity of the following code snippet.

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

fn process_messages(messages: &[Message]) {
    for msg in messages {
        match msg {
            Message::Quit => println!("Quit message"),
            Message::Move { x, y } => println!("Move to {}, {}", x, y),
            Message::Write(text) => println!("Text message: {}", text),
            Message::ChangeColor(r, g, b) => println!("Change color to {}, {}, {}", r, g, b),
        }
    }
}

This code defines an enum with different data types and processes a list of such messages one by one.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: Looping through each message in the list.
• How many times: Once for each message in the input slice.

How Execution Grows With Input

As the number of messages grows, the program processes each message once.

Input Size (n)	Approx. Operations
10	10 message checks and prints
100	100 message checks and prints
1000	1000 message checks and prints

Pattern observation: The work grows directly with the number of messages.

Final Time Complexity

Time Complexity: O(n)

This means the time to process messages grows in a straight line as the number of messages increases.

Common Mistake

[X] Wrong: "Matching on enums with data takes more time for complex data types like strings, so it grows faster than the number of messages."

[OK] Correct: Matching just checks the variant type quickly; the time mainly depends on how many messages you process, not the data size inside each enum variant.

Interview Connect

Understanding how enum processing scales helps you explain how your code handles different data efficiently, a useful skill in many coding tasks.

Self-Check

"What if we added nested loops inside the match arms that process data inside each enum variant? How would the time complexity change?"

Practice

1. What is the main purpose of enums with data in Rust?

easy

A. To group related values that can be different types under one name

B. To create multiple copies of the same data

C. To perform arithmetic operations on numbers

D. To store only strings in a list

Solution

1. Step 1: Understand what enums with data do

   Enums with data allow each variant to hold different types or amounts of data, grouping related but different information.

2. Step 2: Compare options with this understanding

   Only To group related values that can be different types under one name correctly describes grouping related values of different types under one name.

3. Final Answer:

   To group related values that can be different types under one name -> Option A

4. Quick Check:

   Enums with data = group different types [OK]

Hint: Enums group different data types under one name [OK]

Common Mistakes:

• Thinking enums only store one data type
• Confusing enums with arrays or vectors
• Assuming enums perform calculations

2. Which of the following is the correct syntax to define an enum variant with data in Rust?

easy

A. enum Color { Red(u8, u8, u8), Blue }

B. enum Color { Red = (u8, u8, u8), Blue }

C. enum Color { Red: (u8, u8, u8), Blue }

D. enum Color { Red -> (u8, u8, u8), Blue }

Solution

1. Step 1: Recall enum variant syntax with data

   In Rust, enum variants with data are defined by listing the variant name followed by parentheses containing the data types.

2. Step 2: Check each option

   enum Color { Red(u8, u8, u8), Blue } uses correct syntax: Red(u8, u8, u8). Options A, B, and C use invalid syntax with ->, =, or : which are incorrect for enum variant data.

3. Final Answer:

   enum Color { Red(u8, u8, u8), Blue } -> Option A

4. Quick Check:

   Variant with data uses parentheses () [OK]

Hint: Use parentheses () after variant name for data [OK]

Common Mistakes:

• Using = instead of () for variant data
• Using : or -> which are invalid here
• Forgetting parentheses for data

3. What will be the output of this Rust code?

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

fn main() {
    let msg = Message::Move { x: 10, y: 20 };
    match msg {
        Message::Quit => println!("Quit"),
        Message::Move { x, y } => println!("Move to {}, {}", x, y),
        Message::Write(text) => println!("Write {}", text),
    }
}

medium

A. Compilation error

B. Quit

C. Write 10, 20

D. Move to 10, 20

Solution

1. Step 1: Identify the enum variant used

   The variable msg is assigned Message::Move with x=10 and y=20.

2. Step 2: Match arms and output

   The match statement checks msg. For Message::Move, it prints "Move to {}, {}" with x and y values, so output is "Move to 10, 20".

3. Final Answer:

   Move to 10, 20 -> Option D

4. Quick Check:

   Match Message::Move prints coordinates [OK]

Hint: Match variant and print its data fields [OK]

Common Mistakes:

• Confusing variant names
• Expecting Quit or Write output
• Thinking code won't compile

4. The following Rust code has an error. What is the problem?

enum Shape {
    Circle(f64),
    Rectangle { width: f64, height: f64 },
}

fn area(shape: Shape) -> f64 {
    match shape {
        Shape::Circle(radius) => 3.14 * radius * radius,
        Shape::Rectangle(width, height) => width * height,
    }
}

medium

A. Missing semicolon after match arms

B. Circle variant should have named fields

C. Incorrect pattern for Rectangle variant in match

D. Function return type should be i32

Solution

1. Step 1: Check enum variant definitions

   Circle has tuple data (f64), Rectangle has named fields { width, height }.

2. Step 2: Check match patterns

   Circle pattern is correct. Rectangle pattern uses (width, height) which is wrong; it should use { width, height } to match named fields.

3. Final Answer:

   Incorrect pattern for Rectangle variant in match -> Option C

4. Quick Check:

   Match named fields with braces {} [OK]

Hint: Match named fields with braces {}, tuple fields with () [OK]

Common Mistakes:

• Using parentheses for named fields
• Ignoring pattern mismatch errors
• Changing return type unnecessarily

5. Given this enum and function, what is the output?

enum Event {
    Click { x: i32, y: i32 },
    KeyPress(char),
    Resize(u32, u32),
}

fn describe(event: Event) -> String {
    match event {
        Event::Click { x, y } if x > 0 && y > 0 => format!("Clicked at positive coords: {}, {}", x, y),
        Event::Click { .. } => "Clicked at non-positive coords".to_string(),
        Event::KeyPress(c) if c.is_alphabetic() => format!("Key pressed: {}", c),
        Event::KeyPress(_) => "Non-alphabetic key pressed".to_string(),
        Event::Resize(w, h) if w == h => "Resized to square".to_string(),
        Event::Resize(_, _) => "Resized to rectangle".to_string(),
    }
}

fn main() {
    let e = Event::Resize(100, 100);
    println!("{}", describe(e));
}

hard

A. Clicked at positive coords: 100, 100

B. Resized to square

C. Resized to rectangle

D. Non-alphabetic key pressed

Solution

1. Step 1: Identify the enum variant and values

   The event is Event::Resize with width=100 and height=100.

2. Step 2: Match arms with conditions

   The Resize arm with condition w == h matches because 100 == 100, so it returns "Resized to square".

3. Final Answer:

   Resized to square -> Option B

4. Quick Check:

   Resize with equal sides = square [OK]

Hint: Check match guards (if conditions) carefully [OK]

Common Mistakes:

• Ignoring if conditions in match arms
• Confusing Resize with Click variant
• Assuming default arm without conditions