Answer.

Background

Many programming languages allow the use of null values, leading to null pointer dereference errors at runtime. In Rust, a universal type Option<T> has been introduced for the explicit representation of optional values, which ensures safety and, importantly, forces consideration of the case where a value is absent.

Problem

The absence of a value (for instance, if the search result is not found) often leads to runtime errors if this is not reflected in the type. Safe and explicit handling of the empty value case reduces the number of bugs.

Solution

The Option<T> type is implemented as an enum with two variants: Some(T) (value is present) and None (value is absent). This allows the compiler to force the programmer to consider both cases. Any use of an optional value without an explicit check results in a compilation error.

Code example:

fn divide(a: i32, b: i32) -> Option<i32> {
    if b == 0 { None } else { Some(a / b) }
}

let res = divide(6, 3);
match res {
    Some(result) => println!("Result: {}", result),
    None => println!("Division by zero!"),
}

Key features:

No null pointers: the absence of a value is part of the type, not a magic value.
The developer is required to handle both cases — presence and absence of a value.
Compatible with pattern matching, which is convenient for flexible logic handling.

Tricky questions.

Is Option<T> a zero-cost abstraction, or does each Option variable take up more space?

Yes, in most cases Option<T> is zero-cost when the type T cannot take on a "null" value (e.g., reference type or Box<T>). Rust utilizes a "nullable pointer optimization", so no additional memory is required.

let value: Option<&u32> = None;
// Does not take up more space than a regular reference.

Can unwrap be used fearlessly?

No, unwrap() panics when the value is None. It should only be used when it is guaranteed that the value is present, or prefer using unwrap_or, unwrap_or_else, or pattern matching.

How does Option differ from references (&T, Option<&T>)?

A reference always points to an existing value. If the value is absent, Option<&T> should be used to explicitly reflect "may be nothing". Using Option instead of a direct reference prevents null pointer races.

Typical mistakes and anti-patterns

Using unwrap widely without checks, leading to panics.
Mixing Option<&T> and references when the choice is not justified by logic.
Casting Option to Result or another type without a conscious choice.

Real-life example

Negative case

A function returns a search result through Option, but the calling code uses unwrap, assuming there is always a result. In reality, if the value is absent, the program crashes in production.

Pros:

Concise code during the prototyping phase.

Cons:

Undetected situations can easily be overlooked, possibly leading to ugly application termination.

Positive case

The code uses match to handle Option, all cases are explicitly documented and covered by tests.