Chapter 14: Option Types

This chapter introduces Rust’s Option<T> type, a fundamental mechanism for dealing with values that might be absent. C programs often rely on conventions like NULL pointers or special ‘sentinel’ values (e.g., -1, EOF) to signal the absence of a value. Rust, in contrast, encodes this possibility directly into the type system using Option<T>. While this explicit approach requires handling the absence case, it significantly enhances safety and clarity by preventing errors equivalent to null pointer dereferences at compile time.

14.1 Representing Absence: The `Option<T>` Enum

In many programming scenarios, a function might not be able to return a meaningful value, or a data structure might have fields that are not always present. C handles this through NULL pointers or application-specific sentinel values. Rust provides a single, unified, and type-safe solution: the Option<T> enum.

14.1.1 Definition of `Option<T>`

The Option<T> enum is defined in the Rust standard library as follows:

#![allow(unused)]
fn main() {
enum Option<T> {
    Some(T), // Represents the presence of a value of type T
    None,    // Represents the absence of a value
}
}

Some(T): A variant that wraps or contains a value of type T.
None: A variant that indicates the absence of a value. It holds no data.

The variants Some and None are included in Rust’s prelude, meaning they are available in any scope without needing an explicit use statement. You can create Option values directly:

#![allow(unused)]
fn main() {
let number: Option<i32> = Some(42);
let no_number: Option<i32> = None; // Type annotation needed here or from context
}

Type Inference and None

While Rust’s type inference often deduces T in Some(T) from the contained value, None itself doesn’t carry type information. Therefore, when using None, the compiler needs context to determine the full Option<T> type. If the context (like a variable type annotation or function signature) doesn’t provide it, you must specify the type explicitly:

fn main() {
    // Valid: Type is inferred from the variable declaration
    let maybe_float: Option<f64> = None;
    println!("maybe_float: {:?}", maybe_float);

    // Valid: Type is inferred from function signature
    fn requires_option_i32(_opt: Option<i32>) {}
    requires_option_i32(None);

    // Invalid: Compiler cannot infer T in Option<T>
    // let ambiguity = None; // Error: type annotations needed
}

14.1.2 Advantages Over C’s Approaches

Using an explicit type like Option<T> provides significant benefits compared to C’s NULL pointers and sentinel values:

Compile-Time Safety: The Rust compiler mandates that you handle both the Some(T) and None cases before you can use the potential value T. You cannot simply use an Option<T> as if it were a T. This prevents accidental dereferencing of a “null” equivalent at runtime.
Clarity and Explicitness: Function signatures (fn process_data() -> Option<Output>) and struct fields (config_value: Option<String>) explicitly declare whether a value is optional. This improves code readability and acts as documentation, unlike C where checking for NULL relies on convention and programmer memory.
Universality: Option<T> works consistently for any type T, including primitive types (like i32, bool), heap-allocated types (String, Vec<T>), and references (&T). This eliminates the need for ad-hoc sentinel values, which can be error-prone (e.g., if -1 is used as a sentinel but is also a valid data point).

14.1.3 The “Billion-Dollar Mistake” Context

The concept of null references, introduced by Sir Tony Hoare in 1965, has been retrospectively described by him as a “billion-dollar mistake” due to the vast number of bugs, security vulnerabilities, and system crashes caused by null pointer exceptions over the decades. Rust’s Option<T> directly addresses this by integrating the notion of absence into the type system, making the handling of such cases mandatory rather than optional.

14.1.4 `NULL` Pointers (C) vs. `Option<T>` (Rust)

In C, any pointer T* can potentially be NULL. Dereferencing a NULL pointer results in undefined behavior, typically a program crash. The responsibility to check for NULL before dereferencing rests entirely with the programmer.

// C example: Potential null pointer issue
#include <stdio.h>
#include <stdbool.h>

int* find_item(int data[], size_t len, int target) {
    for (size_t i = 0; i < len; ++i) {
        if (data[i] == target) {
            return &data[i]; // Return address if found
        }
    }
    return NULL; // Return NULL if not found
}

int main() {
    int items[] = {1, 2, 3};
    int* found = find_item(items, 3, 2);
    // Programmer MUST check for NULL
    if (found != NULL) {
        printf("Found: %d\n", *found); // Safe dereference
    } else {
        printf("Item not found.\n");
    }

    int* not_found = find_item(items, 3, 5);
    // Forgetting the check leads to undefined behavior (likely crash)
    // printf("Value: %d\n", *not_found); // DANGER: Potential NULL dereference

    return 0;
}

In Rust, a standard reference &T or &mut T is guaranteed by the compiler to never be null. To represent an optional value (including optional references), you must use Option<T> (or Option<&T>, Option<Box<T>>, etc.). The Rust compiler enforces that you handle the None case before you can access the underlying value.

// Rust equivalent: Compile-time safety
fn find_item(data: &[i32], target: i32) -> Option<&i32> {
    for item in data {
        if *item == target {
            return Some(item); // Return Some(reference) if found
        }
    }
    None // Return None if not found
}

fn main() {
    let items = [1, 2, 3];
    let found = find_item(&items, 2);

    // Compiler requires handling both Some and None
    match found {
        Some(value) => println!("Found: {}", value), // Access value safely
        None => println!("Item not found."),
    }

    let not_found = find_item(&items, 5);
    // This would be a COMPILE-TIME error, not a runtime crash:
    // println!("Value: {}", *not_found); // Error: cannot dereference `Option<&i32>`

    // Using if let for convenience when only handling Some:
    if let Some(value) = not_found {
        println!("Found: {}", value);
    } else {
        println!("Item 5 not found.");
    }
}

This fundamental difference shifts potential null-related errors from unpredictable runtime failures to errors caught during compilation.

14.2 Working with `Option<T>`

Rust offers several idiomatic ways to work with Option values, balancing safety and conciseness.

14.2.1 Basic Checks: `is_some()`, `is_none()`, and Comparison

Before diving into pattern matching, it’s useful to know the simplest ways to check the state of an Option:

is_some(&self) -> bool: Returns true if the Option is a Some value.
is_none(&self) -> bool: Returns true if the Option is a None value.

These methods are convenient for simple conditional logic where you don’t immediately need the inner value.

fn main() {
    let some_value: Option<i32> = Some(10);
    let no_value: Option<i32> = None;

    if some_value.is_some() {
        println!("some_value contains a value.");
    }

    if no_value.is_none() {
        println!("no_value does not contain a value.");
    }

    // Note: You can also compare directly with None
    if some_value != None {
         println!("some_value is not None.");
    }
    if no_value == None {
         println!("no_value is None.");
    }
}

Comparison with None: Rust allows direct comparison (== or !=) between an Option<T> and None. This works because Option<T> implements the PartialEq trait. While syntactically valid and sometimes seen, using is_some() or is_none() is often considered more idiomatic Rust, clearly expressing the intent of checking the Option’s state rather than performing a value comparison. Furthermore, is_some() and is_none() can sometimes be clearer when dealing with complex types or nested options.

14.2.2 Pattern Matching: `match` and `if let`

The most fundamental way to handle Option is pattern matching. The match expression ensures all possibilities (Some and None) are considered:

// Use integer division for this example
fn divide(numerator: i32, denominator: i32) -> Option<i32> {
    if denominator == 0 {
        None // Integer division by zero is problematic
    } else {
        Some(numerator / denominator) // Result is valid
    }
}

fn main() {
    let result1 = divide(10, 2);
    match result1 {
        Some(value) => println!("10 / 2 = {}", value),
        None => println!("Division by zero attempted."),
    }

    let result2 = divide(5, 0);
    match result2 {
        Some(value) => println!("5 / 0 = {}", value), // This branch won't run
        None => println!("Cannot divide 5 by 0"),
    }
}

If you only need to handle the Some case (and possibly have a fallback for None), if let is often more concise:

fn main() {
    let maybe_name: Option<String> = Some("Alice".to_string());

    if let Some(name) = maybe_name {
        println!("Name found: {}", name);
        // 'name' is the String value, moved out of the Option here.
        // If you need to keep maybe_name intact, match on &maybe_name
        // or use maybe_name.as_ref().
    } else {
        println!("No name provided.");
    }

    let no_name: Option<String> = None;
    if let Some(name) = no_name {
        // This block is skipped
        println!("This name won't be printed: {}", name);
    } else {
        println!("The second option contained no name.");
    }
}

14.2.3 The `?` Operator for Propagation

The ? operator provides a convenient way to propagate None values up the call stack, similar to how it propagates errors with Result<T, E>. When applied to an Option<T> value within a function that itself returns Option:

If the value is Some(x), the expression evaluates to x.
If the value is None, the ? operator immediately returns None from the enclosing function.

// Gets the first character of the first word, if both exist.
fn get_first_char_of_first_word(text: &str) -> Option<char> {
    // split_whitespace().next() returns Option<&str>
    let first_word = text.split_whitespace().next()?;
    // Returns None if text is empty/whitespace

    // chars().next() returns Option<char>
    let first_char = first_word.chars().next()?;
    // Returns None if word is empty (rare)

    Some(first_char) // Only reached if both operations yielded Some
}

fn main() {
    let text1 = "Hello World";
    println!("Text 1: First char is {:?}", get_first_char_of_first_word(text1));

    let text2 = "    "; // Only whitespace
    println!("Text 2: First char is {:?}", get_first_char_of_first_word(text2));

    let text3 = ""; // Empty string
    println!("Text 3: First char is {:?}", get_first_char_of_first_word(text3));
}

Output:

Text 1: First char is Some('H')
Text 2: First char is None
Text 3: First char is None

This dramatically simplifies code involving sequences of operations where any step might yield None.

14.2.4 Accessing the Value Directly

While pattern matching is the safest approach, several methods allow direct access or providing defaults.

Unsafe Unwrapping (Use with Extreme Caution)

These methods extract the value from Some(T). However, if called on a None value, they will cause the program to panic (an unrecoverable error, similar to an unhandled exception or assertion failure).

unwrap(): Returns the value inside Some(T). Panics if the Option is None.
expect(message: &str): Same as unwrap(), but panics with the custom message string, aiding debugging.

fn main() {
    let value = Some(10);
    println!("Value: {}", value.unwrap()); // OK, prints 10

    let no_value: Option<i32> = None;
    // The following line would panic with a generic message:
    // println!("This panics: {}", no_value.unwrap());

    // Using expect provides a clearer error message upon panic:
    let config_setting: Option<String> = None;
    // The following line would panic with "Missing required configuration setting!":
    // let setting = config_setting.expect("Missing required configuration setting!");
}

Use unwrap() and expect() sparingly. They are appropriate mainly in tests or situations where None genuinely represents a logical impossibility or programming error that should halt the program. In most application logic, prefer safer alternatives.

Safe Access with Defaults

These methods provide safe ways to get the contained value or a default if the Option is None. They never panic.

unwrap_or(default: T): Returns the value inside Some(T), or returns the default value if the Option is None. The default value is evaluated eagerly.
unwrap_or_else(f: F) where F: FnOnce() -> T: Returns the value inside Some(T). If the Option is None, it calls the closure f and returns the result. The closure is only called if needed (lazy evaluation), which is useful if computing the default is expensive.

fn main() {
    let maybe_count: Option<i32> = Some(5);
    let no_count: Option<i32> = None;

    // Using unwrap_or:
    println!("Count or default 0: {}", maybe_count.unwrap_or(0)); // Prints 5
    println!("Count or default 0: {}", no_count.unwrap_or(0));    // Prints 0

    // Using unwrap_or_else:
    let compute_default = || {
        println!("Computing the default value...");
        -1 // The default value
    };

    println!("Count or computed: {}", maybe_count.unwrap_or_else(compute_default));
    // Above line prints 5 (closure is not called)

    println!("Count or computed: {}", no_count.unwrap_or_else(compute_default));
    // Above line prints "Computing the default value..." and then -1
}

Output:

Count or default 0: 5
Count or default 0: 0
Count or computed: 5
Computing the default value...
Count or computed: -1

14.2.5 Combinators: Transforming `Option` Values

Option<T> provides several combinator methods. These are higher-order functions that allow transforming or chaining Option values elegantly, often avoiding explicit match or if let blocks.

map<U, F>(self, f: F) -> Option where F: FnOnce(T) -> U: If self is Some(value), applies the function f to value and returns Some(f(value)). If self is None, returns None.

fn main() {
    let maybe_string = Some("Rust");
    let length: Option<usize> = maybe_string.map(|s| s.len());
    println!("Length of Some(\"Rust\"): {:?}", length); // Some(4)

    let no_string: Option<&str> = None;
    let no_length: Option<usize> = no_string.map(|s| s.len());
    println!("Length of None: {:?}", no_length); // None
}

filter(self, predicate: P) -> Option<T> where P: FnOnce(&T) -> bool: If self is Some(value) and predicate(&value) returns true, returns Some(value). Otherwise (if self is None or predicate returns false), returns None.

fn main() {
    let some_even = Some(4);
    let filtered_even = some_even.filter(|&x| x % 2 == 0);
    println!("Filtered Some(4): {:?}", filtered_even); // Some(4)

    let some_odd = Some(3);
    let filtered_odd = some_odd.filter(|&x| x % 2 == 0);
    println!("Filtered Some(3): {:?}", filtered_odd); // None

    let none_value: Option<i32> = None;
    let filtered_none = none_value.filter(|&x| x > 0);
    println!("Filtered None: {:?}", filtered_none); // None
}

and_then<U, F>(self, f: F) -> Option where F: FnOnce(T) -> Option: If self is Some(value), calls the function f with value. The result of f (which is itself an Option) is returned. If self is None, returns None. This is useful for chaining operations that each might return None, especially when combined with other combinators like filter. It’s sometimes called “flat map”.

// Try to parse a string into a positive integer
fn parse_positive(s: &str) -> Option<u32> {
    s.parse::<u32>().ok() // Returns Option<u32>
     .filter(|&n| n > 0)  // filter keeps Some only if condition met
}

fn main() {
    let maybe_num_str = Some("123");
    let parsed = maybe_num_str.and_then(parse_positive);
    println!("Parsed '123': {:?}", parsed); // Some(123)

    let maybe_neg_str = Some("-5");
    let parsed_neg = maybe_neg_str.and_then(parse_positive);
    println!("Parsed '-5': {:?}", parsed_neg);
    // None (parse fails or filter fails depending on parse impl)

    let maybe_zero_str = Some("0");
    let parsed_zero = maybe_zero_str.and_then(parse_positive);
    println!("Parsed '0': {:?}", parsed_zero);
    // None (parse ok, but filter fails)

    let maybe_invalid_str = Some("abc");
    let parsed_invalid = maybe_invalid_str.and_then(parse_positive);
    println!("Parsed 'abc': {:?}", parsed_invalid); // None (parse fails)

    let no_str: Option<&str> = None;
    let parsed_none = no_str.and_then(parse_positive);
    println!("Parsed None: {:?}", parsed_none); // None
}

or(self, other: Option<T>) -> Option<T>: Returns self if it is Some(value), otherwise returns other. Eagerly evaluates other.

or_else<F>(self, f: F) -> Option<T> where F: FnOnce() -> Option<T>: Returns self if it is Some(value), otherwise calls f and returns its result. Lazily evaluates f.

fn main() {
    let primary: Option<&str> = None;
    let secondary = Some("fallback");
    println!("Primary or secondary: {:?}", primary.or(secondary));
    // Some("fallback")

    let primary_present = Some("primary_val");
    println!("Primary or secondary: {:?}", primary_present.or(secondary));
    // Some("primary_val")

    let compute_fallback = || {
        println!("Computing fallback Option...");
        Some("computed")
    };
    println!("None or_else computed: {:?}", primary.or_else(compute_fallback));
    // Prints "Computing..." then Some("computed")

    println!("Some or_else comp: {:?}", primary_present.or_else(compute_fallback));
    // Prints Some("primary_val"), closure is not called.
}

flatten(self) -> Option (where T is Option): Converts an Option<Option> into an Option. Returns None if the outer or inner option is None.

fn main() {
    let nested_some: Option<Option<i32>> = Some(Some(10));
    println!("Flatten Some(Some(10)): {:?}", nested_some.flatten()); // Some(10)

    let nested_none: Option<Option<i32>> = Some(None);
    println!("Flatten Some(None): {:?}", nested_none.flatten()); // None

    let outer_none: Option<Option<i32>> = None;
    println!("Flatten None: {:?}", outer_none.flatten()); // None
}

zip(self, other: Option) -> Option<(T, U)>: If both self and other are Some, returns Some((T, U)) containing a tuple of their values. If either is None, returns None.

fn main() {
    let x = Some(1);
    let y = Some("hello");
    let z: Option<i32> = None;

    println!("Zip Some(1) and Some(\"hello\"): {:?}", x.zip(y));
    // Some((1, "hello"))
    println!("Zip Some(1) and None: {:?}", x.zip(z)); // None
}

take(&mut self) -> Option<T>: Takes the value out of the Option, leaving None in its place. Requires a mutable reference (&mut Option<T>) because it modifies the original Option. Useful for transferring ownership out of an Option stored in a struct field or mutable variable.

fn main() {
    let mut optional_data = Some(String::from("Important Data"));
    println!("Before take: {:?}", optional_data); // Some("Important Data")

    let taken_data = optional_data.take(); // Moves String out, leaves None
    println!("Taken data: {:?}", taken_data); // Some("Important Data")
    println!("After take: {:?}", optional_data); // None

    let mut already_none: Option<i32> = None;
    let taken_none = already_none.take();
    println!("Taken from None: {:?}", taken_none); // None
    println!("None after take: {:?}", already_none); // None
}

as_ref(&self) -> Option<&T> / as_mut(&mut self) -> Option<&mut T>: Converts an Option<T> into an Option containing a reference (&T or &mut T) to the value inside, without taking ownership. Crucial when you need to inspect or modify the value within an Option without consuming it.

fn process_optional_string(opt_str: &Option<String>) {
    // We only have a reference to the Option<String>
    // Use as_ref() to get Option<&String> for matching/mapping
    match opt_str.as_ref() {
        Some(s_ref) =>
            println!("String found (ref): '{}', length: {}", s_ref, s_ref.len()),
        None => println!("No string found (ref)."),
    }
    // opt_str itself is unchanged
}

fn main() {
    let maybe_message = Some(String::from("Hello"));
    process_optional_string(&maybe_message);
    // maybe_message still owns the String "Hello"
    println!("Original option after ref check: {:?}", maybe_message);
}

This section covers the most commonly used combinators. For a comprehensive list, refer to the official Rust documentation for Option<T>.

14.3 Performance Considerations

C programmers often prioritize performance and low-level control. It’s natural to ask about the runtime and memory costs of using Option<T>.

14.3.1 Memory Layout: Null Pointer Optimization (NPO)

Rust employs a crucial optimization called the Null Pointer Optimization (NPO). When the type T inside an Option<T> has at least one bit pattern that doesn’t represent a valid T value (often, the all-zeroes pattern), Rust uses this “invalid” pattern to represent None.

This optimization frequently applies to types like:

References (&T, &mut T) - which cannot be null.
Boxed pointers (Box<T>) - which point to allocated memory and thus cannot be null.
Function pointers (fn()).
Certain numeric types specifically designed to exclude zero (e.g., std::num::NonZeroUsize, std::num::NonZeroI32).

For these types, Option<T> occupies the exact same amount of memory as T itself. None maps directly to the null/invalid bit pattern, and Some(value) uses the regular valid patterns of T. There is no memory overhead.

use std::mem::size_of;

fn main() {
    // References cannot be null, so Option<&T> uses the null address for None.
    assert_eq!(size_of::<Option<&i32>>(), size_of::<&i32>());
    println!("size_of<&i32>: {}, size_of<Option<&i32>>: {}",
             size_of::<&i32>(), size_of::<Option<&i32>>());

    // Box<T> behaves similarly.
    assert_eq!(size_of::<Option<Box<i32>>>(), size_of::<Box<i32>>());

    // NonZero types explicitly disallow zero, freeing that pattern for None.
    assert_eq!(size_of::<Option<std::num::NonZeroU32>>(),
        size_of::<std::num::NonZeroU32>());
}

If T can use all of its possible bit patterns (like standard integers u8, i32, f64, or simple structs composed only of such types), NPO cannot apply. In these cases, Option<T> typically requires a small amount of extra space (usually 1 byte, sometimes more depending on alignment) for a discriminant tag to indicate whether it’s Some or None, plus the space needed for T itself.

use std::mem::size_of;

fn main() {
    // u8 uses all 256 bit patterns. Option<u8> needs extra space for a tag.
    println!("size_of<u8>: {}", size_of::<u8>());             // Typically 1
    println!("size_of<Option<u8>>: {}", size_of::<Option<u8>>());
    // Typically 2 (1 tag + 1 data)

    // bool uses 1 byte (usually), representing 0 or 1. Value 2 might be used as tag.
    println!("size_of<bool>: {}", size_of::<bool>());             // Typically 1
    println!("size_of<Option<bool>>: {}", size_of::<Option<bool>>());
    // Typically 1 (optimized) or 2
}

Even when a discriminant is needed, the memory overhead is minimal and predictable.

14.3.2 Runtime Cost

Checking an Option<T> (e.g., in a match, via methods like is_some(), or implicitly with ?) involves:

If NPO applies: Comparing the value against the known null/invalid pattern.
If a discriminant exists: Checking the value of the discriminant tag.

Both operations are typically very fast on modern CPUs, usually translating to a single comparison and conditional branch. The compiler can often optimize these checks, especially when methods like map or and_then are chained together. The runtime cost compared to a manual NULL check in C is generally negligible, while the safety gain is immense.

14.3.3 Source Code Verbosity vs. Robustness

Handling Option<T> explicitly can sometimes feel more verbose than C code that might ignore NULL checks or assume a sentinel value isn’t present. However, this perceived verbosity is the source of Rust’s safety guarantee. Methods like ?, combinators (map, and_then, etc.), is_some(), is_none(), and unwrap_or_else significantly reduce the boilerplate compared to writing explicit match statements everywhere, allowing for code that is both safe and expressive.

14.4 Best Practices for Using `Option<T>`

Embrace Option<T>: Use it whenever a value might legitimately be absent. This applies to function return values (e.g., search results, parsing), optional struct fields, and any operation that might “fail” in a non-exceptional way.
Prioritize Safe Handling: Prefer pattern matching (match, if let), basic checks (is_some, is_none), the ? operator (within functions returning Option), or safe methods like unwrap_or, unwrap_or_else, map, and_then, filter, ok_or.
Use unwrap() and expect() Judiciously: Reserve these for situations where None indicates a critical logic error or invariant violation, and immediate program termination (panic) is the desired outcome. Prefer expect("informative message") over unwrap() to aid debugging if a panic occurs.

Leverage Combinators and ? for Conciseness: Chain methods like map, filter, and_then, and use the ? operator to write cleaner, more linear code compared to deeply nested match or if let structures.

// Chaining example: Find the length of the first word, if any.
let text = " Example text ";
let length = text.split_whitespace() // Iterator<Item=&str>
                 .next()             // Option<&str>
                 .map(|word| word.len()); // Option<usize>

match length {
    Some(len) => println!("Length of first word: {}", len),
    None => println!("No words found."),
}

// Using ? inside a function:
fn process_maybe_data(data: Option<DataSource>) -> Option<ProcessedValue> {
    let source = data?;               // Propagate None if data is None
    let intermediate = source.step1()?; // Propagate None if step1 yields None
    let result = intermediate.step2()?; // Propagate None if step2 yields None
    Some(result)
}

Use as_ref() or as_mut() for Borrowing: When you need to work with the value inside an Option<T> via a reference (&T or &mut T) without taking ownership, use my_option.as_ref() or my_option.as_mut(). This yields an Option<&T> or Option<&mut T>, respectively, which is often needed for matching or passing to functions that expect references.

14.5 Practical Examples

Let’s examine how Option<T> is applied in typical programming tasks.

14.5.1 Retrieving Data from Collections

Hash maps and other collections often return Option from lookup operations.

use std::collections::HashMap;

fn main() {
    let mut scores = HashMap::new();
    scores.insert("Alice", 100);
    scores.insert("Bob", 95);

    let alice_score_option = scores.get("Alice"); // Returns Option<&i32>
    match alice_score_option {
        Some(&score) => println!("Alice's score: {}", score),
        // Note the &score pattern
        None => println!("Alice not found."),
    }

    // Using map to process the score if present
    let bob_score_msg = scores.get("Bob") // Option<&i32>
                  .map(|&score| format!("Bob's score: {}", score)) // Option<String>
                  .unwrap_or_else(|| "Bob not found.".to_string()); // String
    println!("{}", bob_score_msg);

    let charlie_score = scores.get("Charlie");
    if charlie_score.is_none() {
        println!("Charlie's score is not available.");
    }
}

Output:

Alice's score: 100
Bob's score: 95
Charlie's score is not available.

14.5.2 Optional Struct Fields

Representing optional configuration or data within structs is a common use case.

struct UserProfile {
    user_id: u64,
    display_name: String,
    email: Option<String>, // Email might not be provided
    location: Option<String>, // Location might be optional
}

impl UserProfile {
    fn new(id: u64, name: String) -> Self {
        UserProfile {
            user_id: id,
            display_name: name,
            email: None,
            location: None,
        }
    }

    fn with_email(mut self, email: String) -> Self {
        self.email = Some(email);
        self
    }

    fn with_location(mut self, location: String) -> Self {
        self.location = Some(location);
        self
    }
}

fn main() {
    let user1 = UserProfile::new(101, "Admin".to_string())
                .with_email("admin@example.com".to_string());

    println!("User ID: {}", user1.user_id);
    println!("Display Name: {}", user1.display_name);

    // Use as_deref() to convert Option<String> to Option<&str> before unwrap_or
    // This avoids moving the String out and works well with &str default.
    println!("Email: {}", user1.email.as_deref().unwrap_or("Not provided"));

    // Alternatively, use unwrap_or_else for a String default
    println!("Location: {}", user1.location.unwrap_or_else(|| "Unknown".to_string()));
}

Output:

User ID: 101
Display Name: Admin
Email: admin@example.com
Location: Unknown

14.6 Summary

This chapter explored Rust’s Option<T> enum, a fundamental tool for robustly handling potentially absent values:

Core Concept: Option<T> explicitly represents a value that might be present (Some(T)) or absent (None).
Safety: It eliminates the equivalent of null pointer dereference errors by enforcing compile-time checks for the None case, offering a significant improvement over C’s NULL pointers and sentinel values.
Handling: Option values are typically handled using basic checks (is_some, is_none), pattern matching (match, if let), the ? operator for propagating None, safe unwrapping methods (unwrap_or, unwrap_or_else), or combinator methods.
Combinators: Methods like map, and_then, filter, or_else, zip, flatten, take, as_ref, and as_mut provide powerful and concise ways to manipulate Option values without explicit matching. A comprehensive list is available in the standard library documentation.
Performance: Due to the Null Pointer Optimization (NPO), Option<T> often has zero memory overhead compared to nullable pointers in C. Runtime checks are generally very efficient.
Clarity: Using Option<T> makes the potential absence of a value explicit in function signatures and data structures, improving code clarity, maintainability, and self-documentation.

By incorporating Option<T> into your Rust programming practice, you leverage the type system to build more reliable and easier-to-understand software, catching potential errors related to missing values at compile time rather than encountering them as runtime crashes.

Keyboard shortcuts

Rust for C-Programmers