The Option Type: Rust's Answer to null and undefined

21 min read

Rust has no null and no undefined. Instead, the possibility of “no value” is encoded in the type system with Option<T> — an enum with exactly two variants, Some(value) and None. The compiler then forces you to handle the “missing” case before you can touch the value, which eliminates an entire category of runtime crashes that plague TypeScript and JavaScript.

Quick Overview

In TypeScript, any value can secretly be null or undefined, and forgetting to check leads to the infamous TypeError: Cannot read properties of undefined. Rust replaces those two bottom values with a single, explicit type, Option<T>: a value is either Some(T) (present) or None (absent). Because “absent” is a distinct variant rather than a magic value any reference can hold, you cannot accidentally use a missing value — the code simply will not compile until you account for None.

TypeScript/JavaScript Example

1
// TypeScript - absence is expressed with null/undefined and optional fields
2
interface User {
3
  id: number;
4
  name: string;
5
  email?: string; // optional => string | undefined
6
}
7

8
const users: User[] = [
9
  { id: 1, name: "Ada", email: "ada@corp.dev" },
10
  { id: 2, name: "Grace" }, // no email
11
];
12

13
function findUser(id: number): User | undefined {
14
  return users.find((u) => u.id === id);
15
}
16

17
// The optional chaining + nullish coalescing dance:
18
function contactLine(id: number): string {
19
  const user = findUser(id);
20
  const email = user?.email ?? "no-email-on-file";
21
  return `${user?.name ?? "unknown"} <${email}>`;
22
}
23

24
console.log(contactLine(1)); // Ada <ada@corp.dev>
25
console.log(contactLine(2)); // Grace <no-email-on-file>
26
console.log(contactLine(99)); // unknown <no-email-on-file>
27

28
// The classic mistake: forgetting the check entirely
29
const u = findUser(99);
30
// console.log(u.name); // compiles only if strictNullChecks is off; crashes at runtime:
31
//   TypeError: Cannot read properties of undefined (reading 'name')

Key points:

find returns User | undefined; ?. and ?? are the tools for handling it.
With strictNullChecks on, TypeScript flags u.name. With it off (still common in legacy codebases), the bug ships and crashes at runtime.
null and undefined are two separate bottom values, and the distinction between them is a frequent source of subtle bugs.

Rust Equivalent

1
// Rust - absence is one explicit type: Option<T>
2
#[derive(Debug)]
3
struct User {
4
    id: u64,
5
    name: String,
6
    email: Option<String>, // explicitly "maybe a String"
7
}
8

9
fn find_user<'a>(users: &'a [User], id: u64) -> Option<&'a User> {
10
    users.iter().find(|u| u.id == id) // `find` returns Option, like Array.find
11
}
12

13
fn contact_line(users: &[User], id: u64) -> String {
14
    find_user(users, id)
15
        .map(|u| {
16
            // as_deref turns Option<String> into Option<&str>; unwrap_or supplies a fallback
17
            let email = u.email.as_deref().unwrap_or("no-email-on-file");
18
            format!("{} <{}>", u.name, email)
19
        })
20
        .unwrap_or_else(|| "unknown user".to_string())
21
}
22

23
fn main() {
24
    let users = vec![
25
        User { id: 1, name: "Ada".to_string(), email: Some("ada@corp.dev".to_string()) },
26
        User { id: 2, name: "Grace".to_string(), email: None },
27
    ];
28

29
    println!("{}", contact_line(&users, 1));  // Ada <ada@corp.dev>
30
    println!("{}", contact_line(&users, 2));  // Grace <no-email-on-file>
31
    println!("{}", contact_line(&users, 99)); // unknown user
32

33
    // The equivalent of "forgetting the check" does not compile:
34
    let u = find_user(&users, 99);
35
    // println!("{}", u.name); // does not compile (error[E0609]: no field `name` on Option<&User>)
36
    println!("{u:?}"); // None
37
}

Verified output:

1
Ada <ada@corp.dev>
2
Grace <no-email-on-file>
3
unknown user
4
None

Key points:

One type, Option<T>, replaces both null and undefined.
You cannot reach the inner User without first dealing with the None case — the “forgotten check” is a compile error, not a runtime crash.
map / unwrap_or / as_deref are the idiomatic counterparts to ?. and ??.

Detailed Explanation

`Option<T>` is just an enum

There is nothing magical about Option. It is defined in the standard library, roughly, as:

1
// Conceptual: this is essentially how the standard library defines Option.
2
enum MyOption<T> {
3
    Some(T),
4
    None,
5
}
6

7
fn main() {
8
    let a: MyOption<i32> = MyOption::Some(3);
9
    let b: MyOption<i32> = MyOption::None;
10

11
    let label = match a {
12
        MyOption::Some(n) => format!("value {n}"),
13
        MyOption::None => "nothing".to_string(),
14
    };
15
    let label2 = match b {
16
        MyOption::Some(n) => format!("value {n}"),
17
        MyOption::None => "nothing".to_string(),
18
    };
19
    println!("{label} / {label2}"); // value 3 / nothing
20
}

Some and None are variants of the enum, parameterized over a generic type T. (Enums and their data-carrying variants are covered in enums.md; generics get full treatment in Section 09.) Because Option is so fundamental, Some and None are in Rust’s prelude — you never need to write Option::Some or import anything.

Note: Unlike a TypeScript union T | undefined, the Some wrapper is a real, named variant. To get at the T inside, you must explicitly unwrap it — there is no implicit “the value is just there.” This is what makes the absence impossible to ignore.

Creating and inspecting Options

1
fn main() {
2
    let present: Option<i32> = Some(42);
3
    let absent: Option<i32> = None;
4

5
    println!("{present:?}"); // Some(42)
6
    println!("{absent:?}");  // None
7

8
    // Quick boolean checks (rarely the best tool, but they exist)
9
    println!("{} {}", present.is_some(), present.is_none()); // true false
10
    println!("{} {}", absent.is_some(), absent.is_none());   // false true
11
}

When you write a bare None, Rust sometimes cannot infer T, so you annotate either the binding (let absent: Option<i32> = None;) or the value (None::<i32>).

Getting the value out: pattern matching

The most fundamental way to handle an Option is match, which forces you to cover both variants:

1
fn find_user(name: &str) -> Option<&'static str> {
2
    match name {
3
        "alice" => Some("Alice Smith"),
4
        "bob" => Some("Bob Jones"),
5
        _ => None,
6
    }
7
}
8

9
fn main() {
10
    // `match` is exhaustive: the compiler rejects it if you forget `None`.
11
    match find_user("alice") {
12
        Some(full_name) => println!("found {full_name}"),
13
        None => println!("no user"),
14
    }
15

16
    // `if let` when you only care about the Some case
17
    if let Some(full_name) = find_user("bob") {
18
        println!("if-let found {full_name}");
19
    }
20

21
    // `let ... else` to bind-or-bail (stabilized in Rust 1.65)
22
    let Some(first) = find_user("alice") else {
23
        println!("no user — returning early");
24
        return;
25
    };
26
    println!("let-else got {first}");
27
}

match, if let, and let ... else are all covered in depth in pattern-matching.md. The key idea here: extracting the inner value is a deliberate act, and the compiler checks that you handled None.

Combinators: the idiomatic alternative to unwrapping

Most real code does not match on every Option. Instead it uses combinator methods — small functions on Option that transform or unwrap it. These are the direct counterparts to TypeScript’s ?. and ??.

1
fn main() {
2
    // map: transform the inner value if present (like x?.f())
3
    let len: Option<usize> = Some("hello").map(|s| s.len());
4
    println!("{len:?}"); // Some(5)
5
    let none_len: Option<usize> = None::<&str>.map(|s| s.len());
6
    println!("{none_len:?}"); // None
7

8
    // and_then: chain operations that THEMSELVES return Option (a flatMap)
9
    let parsed: Option<i32> = Some("42").and_then(|s| s.parse::<i32>().ok());
10
    println!("{parsed:?}"); // Some(42)
11
    let bad: Option<i32> = Some("abc").and_then(|s| s.parse::<i32>().ok());
12
    println!("{bad:?}"); // None
13

14
    // unwrap_or: supply a fallback value (like ?? )
15
    let port: u16 = None.unwrap_or(8080);
16
    println!("{port}"); // 8080
17

18
    // unwrap_or_else: compute the fallback lazily (only runs if None)
19
    let value = None.unwrap_or_else(|| expensive_default());
20
    println!("{value}"); // 99
21

22
    // unwrap_or_default: use the type's Default::default()
23
    let count: i32 = None.unwrap_or_default();
24
    println!("{count}"); // 0
25

26
    // filter: keep Some only if a predicate holds
27
    println!("{:?} {:?}", Some(4).filter(|n| n % 2 == 0), Some(3).filter(|n| n % 2 == 0));
28
    // Some(4) None
29

30
    // or: fall back to another Option
31
    println!("{:?}", None.or(Some("fallback"))); // Some("fallback")
32
}
33

34
fn expensive_default() -> i32 {
35
    99
36
}

Verified output:

1
Some(5)
2
None
3
Some(42)
4
None
5
8080
6
99
7
0
8
Some(4) None
9
Some("fallback")

The crucial pair to internalize:

You want to…	Method	TS analogue
Transform the value but stay inside `Option`	`map`	`x?.f()`
Transform with a function that returns another `Option`	`and_then`	`x?.f()` where `f` may be nullish
Provide a fallback value and leave `Option`	`unwrap_or`	`x ?? fallback`
Provide a fallback computed lazily	`unwrap_or_else`	`x ?? expensiveFallback()`

Tip: Reach for unwrap_or_else over unwrap_or whenever the default is expensive to build (e.g. allocates a String or hits the network). unwrap_or evaluates its argument eagerly, even when the value is Some.

Chaining: a realistic pipeline

Combinators shine when chained, replacing a nest of TypeScript ?./??:

1
fn main() {
2
    // Read a "port" setting that may be missing, whitespace-padded, or unparseable.
3
    let cfg: Option<&str> = Some("  9090 ");
4
    let port: u16 = cfg
5
        .map(|s| s.trim())                  // Option<&str> with trimmed value
6
        .and_then(|s| s.parse::<u16>().ok()) // Option<u16> (parse may fail)
7
        .unwrap_or(8080);                    // final value with a default
8
    println!("port: {port}"); // 9090
9
}

.ok() converts a Result<T, E> into an Option<T> (discarding the error). The reverse — Option to Result — is .ok_or(err), which is how you bridge into the ?-and-Result world covered in Section 08.

The `?` operator with `Option`

The ? operator is short-circuit unwrapping: if the value is Some, it pulls out the inner value; if it is None, it immediately returns None from the enclosing function. This lets you write a chain of fallible lookups linearly, with no nesting:

1
#[derive(Debug)]
2
struct Config {
3
    database: Database,
4
}
5
#[derive(Debug)]
6
struct Database {
7
    url: Option<String>,
8
}
9

10
// `?` on an Option requires the function to ALSO return Option (or Result).
11
fn first_db_host(cfg: &Config) -> Option<String> {
12
    let url = cfg.database.url.as_ref()?; // returns None early if url is None
13
    let host = url.split('/').nth(2)?;    // returns None if there's no 3rd segment
14
    Some(host.to_string())
15
}
16

17
fn main() {
18
    let with_url = Config {
19
        database: Database { url: Some("postgres://db.example.com/app".to_string()) },
20
    };
21
    let without_url = Config {
22
        database: Database { url: None },
23
    };
24

25
    println!("{:?}", first_db_host(&with_url));    // Some("db.example.com")
26
    println!("{:?}", first_db_host(&without_url)); // None
27

28
    // ok_or converts Option -> Result, bridging into the ? + Result world
29
    let ok: Result<i32, &str> = Some(5).ok_or("missing");
30
    let err: Result<i32, &str> = None.ok_or("missing");
31
    println!("{ok:?} / {err:?}"); // Ok(5) / Err("missing")
32
}

Verified output:

1
Some("db.example.com")
2
None
3
Ok(5) / Err("missing")

This is the closest Rust gets to TypeScript’s optional chaining a?.b?.c, but it is more powerful: ? works on any expression that produces an Option, including function calls, parsing, and collection lookups — not just member access.

Warning: ? propagates the absence to the caller. The function that uses ? on an Option must itself return an Option (or a Result, if you ? a Result). You cannot use ? in a function that returns a plain String or i32. The exact compiler error appears in Common Pitfalls.

Borrowing the inner value: `as_ref` and `as_deref`

A subtle but important point unique to Rust: calling a method like unwrap() on an Option<String> moves the String out (ownership rules from Section 05). Often you only want to borrow it. as_ref converts &Option<T> ergonomically into Option<&T>, and as_deref goes one step further to Option<&str> (or Option<&[T]>):

1
fn main() {
2
    let owned: Option<String> = Some("hi".to_string());
3

4
    let borrowed: Option<&String> = owned.as_ref(); // does NOT move `owned`
5
    println!("{:?}", borrowed); // Some("hi")
6
    println!("{:?}", owned);    // still usable: Some("hi")
7

8
    let s: Option<String> = Some("deref".to_string());
9
    let d: Option<&str> = s.as_deref(); // Option<String> -> Option<&str>
10
    println!("{:?}", d); // Some("deref")
11
}

as_deref().unwrap_or("default") is the idiomatic way to read an optional String field as a &str with a fallback, which is exactly what the opening example does.

Key Differences

Concept	TypeScript/JavaScript	Rust
Absence value(s)	`null` and `undefined` (two bottoms)	One type: `Option<T>` with `None`
Can any reference be absent?	Yes — every object can be `null`/`undefined`	No — only `Option<T>` can be `None`
Forgetting the check	Runtime `TypeError` (or hidden if no strict mode)	Compile error — code won’t build
Optional chaining	`a?.b?.c`	`a.and_then(...)` / `?` operator
Nullish coalescing	`x ?? fallback`	`x.unwrap_or(fallback)` / `unwrap_or_else`
Default for missing	`x ?? defaultValue`	`x.unwrap_or_default()`
Runtime cost	A value compared against `null`/`undefined`	Zero-cost: niche-optimized (often same size as `T`)

Why Rust does it this way

The deep reason is the billion-dollar mistake. Tony Hoare, who invented null references in 1965, later called them his billion-dollar mistake because of the countless bugs they caused. Rust’s design response is to make absence a value you opt into per type, rather than a hole in every reference. A String in Rust is always a valid string; if it might be missing, its type is Option<String> and the compiler tracks that fact everywhere.

A pleasant bonus: Option<T> is usually zero-overhead. For types with a “niche” (an unused bit pattern), the compiler represents None using that bit pattern, so Option<&T>, Option<Box<T>>, and Option<NonZero<u32>> are the same size as the value they wrap. There is no boxing and no extra tag word in those cases.

Note: This contrasts sharply with TypeScript, where string | undefined is a compile-time-only construct. TypeScript’s union types are erased at runtime (the JS engine just sees a value that happens to be undefined), whereas Rust monomorphizes Option<T> into a concrete in-memory layout for each T.

Common Pitfalls

Pitfall 1: Calling a method on the `Option` instead of the inner value

A TypeScript habit is to call methods directly, since ?. short-circuits for you. In Rust, Option<&str> is not a &str, so its methods are not available:

1
fn main() {
2
    let name: Option<&str> = Some("Bob");
3
    let shout = name.to_uppercase(); // does not compile
4
    println!("{shout}");
5
}

The real compiler error:

1
error[E0599]: no method named `to_uppercase` found for enum `Option` in the current scope
2
 --> src/main.rs:3:22
3
  |
4
3 |     let shout = name.to_uppercase(); // does not compile
5
  |                      ^^^^^^^^^^^^ method not found in `Option<&str>`
6
  |
7
note: the method `to_uppercase` exists on the type `&str`
8
help: consider using `Option::expect` to unwrap the `&str` value, panicking if the value is an `Option::None`

Fix: transform inside the Option with map: name.map(|s| s.to_uppercase()).

Pitfall 2: Reaching `unwrap()` for “I know it’s there”

unwrap() and expect() extract the value but panic (crash the thread) on None. They are the moral equivalent of pretending a value is non-null:

1
fn main() {
2
    let maybe: Option<i32> = None;
3
    let value = maybe.unwrap(); // panics at runtime
4
    println!("{value}");
5
}

Running it produces a real panic, not a compile error:

1
thread 'main' panicked at src/main.rs:3:23:
2
called `Option::unwrap()` on a `None` value
3
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Fix: use unwrap_or, unwrap_or_else, match, if let, or ? to handle None explicitly. Reserve unwrap() for cases that are provably impossible, and prefer expect("reason") so the panic message documents your assumption.

Pitfall 3: Using `?` in a function that doesn’t return `Option`/`Result`

1
fn third_segment(url: &str) -> String {
2
    let seg = url.split('/').nth(2)?; // does not compile
3
    seg.to_string()
4
}
5

6
fn main() {
7
    println!("{}", third_segment("a/b/c"));
8
}

The real compiler error spells out the requirement exactly:

1
error[E0277]: the `?` operator can only be used in a function that returns `Result` or `Option` (or another type that implements `FromResidual`)
2
 --> src/main.rs:2:36
3
  |
4
1 | fn third_segment(url: &str) -> String {
5
  | ------------------------------------- this function should return `Result` or `Option` to accept `?`
6
2 |     let seg = url.split('/').nth(2)?; // does not compile
7
  |                                    ^ cannot use the `?` operator in a function that returns `String`

Fix: change the return type to Option<String> (and the caller deals with the None), or handle the None locally with unwrap_or.

Pitfall 4: Assuming `None == null` for interop

When serializing to JSON (see Section 15), None typically maps to null or an omitted field, while Some(x) maps to x. There is no JavaScript-style distinction between null and undefined on the Rust side — that nuance has to be configured at the serialization layer (e.g. with serde’s skip_serializing_if).

Best Practices

Prefer combinators to match for simple transforms. opt.map(...).unwrap_or(...) reads more clearly than a three-line match when you are just transforming-or-defaulting.
Use ? to flatten nested optional lookups. A chain of let x = a()?; let y = b(x)?; is far clearer than nested match/if let.
Avoid unwrap()/expect() in library and production code paths. They are fine in tests, prototypes, and genuinely-unreachable cases — and when you do use expect, write a message that explains why it cannot be None.
Borrow with as_ref/as_deref instead of moving. This keeps the original Option usable and avoids unnecessary clones.
Reach for unwrap_or_default() when the natural fallback is the type’s zero/empty value (0, "", vec![]).
Convert at the boundary. Use .ok_or(err) to turn an Option into a Result the moment “missing” should become a reportable error, then let ? carry it upward.

Tip: Clippy will nudge you toward idiomatic choices — for example, it suggests map_or over map(...).unwrap_or(...) in some cases, and flags unwrap() patterns in lints you can opt into. Run cargo clippy regularly.

Real-World Example

A small in-memory user directory backed by a HashMap (collections are covered in Section 07). It shows ? chaining through genuinely-optional fields, plus map + as_deref + unwrap_or fallbacks — the kind of code you write constantly in a service layer.

1
use std::collections::HashMap;
2

3
/// A user profile where several fields are genuinely optional.
4
#[derive(Debug, Clone)]
5
struct User {
6
    id: u64,
7
    name: String,
8
    email: Option<String>,   // not every account verified an email
9
    manager_id: Option<u64>, // the CEO has no manager
10
}
11

12
struct Directory {
13
    users: HashMap<u64, User>,
14
}
15

16
impl Directory {
17
    fn get(&self, id: u64) -> Option<&User> {
18
        self.users.get(&id) // HashMap::get already returns Option
19
    }
20

21
    /// The display name of a user's manager — but only if the user exists,
22
    /// has a manager, and that manager also exists. Any failure -> None.
23
    fn manager_name(&self, id: u64) -> Option<&str> {
24
        let user = self.get(id)?; // user must exist
25
        let manager_id = user.manager_id?; // user must have a manager
26
        let manager = self.get(manager_id)?; // manager must exist
27
        Some(&manager.name)
28
    }
29

30
    /// A printable contact line, with placeholders for missing pieces.
31
    fn contact_line(&self, id: u64) -> String {
32
        self.get(id)
33
            .map(|u| {
34
                let email = u.email.as_deref().unwrap_or("no-email-on-file");
35
                format!("#{} {} <{}>", u.id, u.name, email)
36
            })
37
            .unwrap_or_else(|| "unknown user".to_string())
38
    }
39
}
40

41
fn main() {
42
    let mut users = HashMap::new();
43
    users.insert(1, User { id: 1, name: "Ada".into(),   email: Some("ada@corp.dev".into()), manager_id: None });
44
    users.insert(2, User { id: 2, name: "Grace".into(), email: None,                        manager_id: Some(1) });
45
    let dir = Directory { users };
46

47
    // The ? chain in manager_name short-circuits cleanly:
48
    println!("{:?}", dir.manager_name(2));  // Some("Ada")
49
    println!("{:?}", dir.manager_name(1));  // None  (Ada has no manager)
50
    println!("{:?}", dir.manager_name(99)); // None  (no such user)
51

52
    // map + as_deref + unwrap_or fallbacks:
53
    println!("{}", dir.contact_line(1));  // #1 Ada <ada@corp.dev>
54
    println!("{}", dir.contact_line(2));  // #2 Grace <no-email-on-file>
55
    println!("{}", dir.contact_line(99)); // unknown user
56
}

Verified output:

1
Some("Ada")
2
None
3
None
4
#1 Ada <ada@corp.dev>
5
#2 Grace <no-email-on-file>
6
unknown user

Notice how manager_name reads like a sequence of preconditions, each guarded by ?. The TypeScript equivalent would be a tangle of ?. and intermediate if checks, and a single missed check would crash at runtime instead of being caught by the compiler.

Exercises

Exercise 1: Safe division

Difficulty: Beginner

Objective: Model “this operation might not produce a value” with Option<T>.

Instructions:

Write safe_div(a: f64, b: f64) -> Option<f64> that returns None when b is 0.0 and Some(a / b) otherwise.
In main, print the results of safe_div(10.0, 2.0) and safe_div(1.0, 0.0) with {:?}.
Use unwrap_or to print the result of safe_div(7.0, 0.0) with a fallback of f64::INFINITY.

1
fn safe_div(a: f64, b: f64) -> Option<f64> {
2
    // TODO
3
}
4

5
fn main() {
6
    // TODO: print the three cases
7
}

Solution

1
fn safe_div(a: f64, b: f64) -> Option<f64> {
2
    if b == 0.0 {
3
        None
4
    } else {
5
        Some(a / b)
6
    }
7
}
8

9
fn main() {
10
    println!("{:?}", safe_div(10.0, 2.0)); // Some(5.0)
11
    println!("{:?}", safe_div(1.0, 0.0));  // None
12

13
    let result = safe_div(7.0, 0.0).unwrap_or(f64::INFINITY);
14
    println!("{result}"); // inf
15
}

Verified output:

1
Some(5.0)
2
None
3
inf

Returning Option (rather than throwing or returning a sentinel like NaN) makes the “no result” case impossible for callers to ignore.

Exercise 2: A combinator pipeline

Difficulty: Intermediate

Objective: Replace a ?./?? chain with Option combinators.

Instructions:

Write parse_timeout(raw: Option<&str>) -> u64 that reads a timeout setting.
The setting may be missing (None), surrounded by whitespace, empty, unparseable, or zero.
Trim it, reject empty strings, parse it as a u64, reject 0, and fall back to 30 for any failure.
Use a chain of map, filter, and_then, and unwrap_or — no match or if.
Test with Some(" 60 "), Some("abc"), Some("0"), Some(""), and None.

Solution

1
fn parse_timeout(raw: Option<&str>) -> u64 {
2
    raw.map(|s| s.trim())                // trim whitespace
3
        .filter(|s| !s.is_empty())       // reject empty
4
        .and_then(|s| s.parse::<u64>().ok()) // parse, discarding the error
5
        .filter(|&n| n > 0)              // reject zero
6
        .unwrap_or(30)                   // fall back to the default
7
}
8

9
fn main() {
10
    println!("{}", parse_timeout(Some("  60 "))); // 60
11
    println!("{}", parse_timeout(Some("abc")));   // 30 (parse fails)
12
    println!("{}", parse_timeout(Some("0")));     // 30 (filtered out)
13
    println!("{}", parse_timeout(Some("")));      // 30 (empty)
14
    println!("{}", parse_timeout(None));          // 30 (missing)
15
}

Verified output:

Each combinator handles exactly one failure mode, and a None anywhere in the chain flows straight through to unwrap_or(30).

Exercise 3: `?` through nested optional data

Difficulty: Advanced

Objective: Use the ? operator to traverse deeply-optional data without nesting.

Instructions:

Define three structs: Order { customer: Option<Customer> }, Customer { address: Option<Address> }, and Address { zip: Option<String> }.
Write shipping_zip(order: &Order) -> Option<&str> that returns the zip code only if the customer, the address, and the zip are all present.
Use ? together with as_ref / as_deref so you borrow rather than move.
Test with a fully-populated order, an order whose customer has no address, and an order with no customer.

Solution

1
#[derive(Debug)]
2
struct Order {
3
    customer: Option<Customer>,
4
}
5
#[derive(Debug)]
6
struct Customer {
7
    address: Option<Address>,
8
}
9
#[derive(Debug)]
10
struct Address {
11
    zip: Option<String>,
12
}
13

14
fn shipping_zip(order: &Order) -> Option<&str> {
15
    let customer = order.customer.as_ref()?; // Option<&Customer>
16
    let address = customer.address.as_ref()?; // Option<&Address>
17
    let zip = address.zip.as_deref()?;        // Option<&str>
18
    Some(zip)
19
}
20

21
fn main() {
22
    let full = Order {
23
        customer: Some(Customer {
24
            address: Some(Address { zip: Some("94107".to_string()) }),
25
        }),
26
    };
27
    let no_addr = Order {
28
        customer: Some(Customer { address: None }),
29
    };
30
    let no_cust = Order { customer: None };
31

32
    println!("{:?}", shipping_zip(&full));    // Some("94107")
33
    println!("{:?}", shipping_zip(&no_addr)); // None
34
    println!("{:?}", shipping_zip(&no_cust)); // None
35
}

Verified output:

1
Some("94107")
2
None
3
None

This is the Rust counterpart to order?.customer?.address?.zip — but ? works on owned and borrowed Options alike, and the compiler guarantees you handled every None.

Summary

What you’ve learned:

Rust has no null/undefined; absence is modeled by the Option<T> enum (Some(T) or None).
The compiler forces you to handle None, turning “forgot the null check” into a compile error.
map and and_then are the ?. analogues; unwrap_or/unwrap_or_else/unwrap_or_default are the ?? analogues.
The ? operator unwraps Some or returns None early — flattening nested optional lookups — and requires the enclosing function to return Option (or Result).
unwrap()/expect() panic on None; prefer explicit handling, and use as_ref/as_deref to borrow rather than move the inner value.

The mental model: Option<T> is the type that says, out loud and in the signature, “this might not be here.” TypeScript hides that possibility in every reference and hopes you remember to check; Rust makes it a visible, compiler-enforced part of the type.

The Option Type: Rust's Answer to null and undefined

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

Option<T> is just an enum

Creating and inspecting Options

Getting the value out: pattern matching

Combinators: the idiomatic alternative to unwrapping

Chaining: a realistic pipeline

The ? operator with Option

Borrowing the inner value: as_ref and as_deref

Key Differences

Why Rust does it this way

Common Pitfalls

Pitfall 1: Calling a method on the Option instead of the inner value

Pitfall 2: Reaching unwrap() for “I know it’s there”

Pitfall 3: Using ? in a function that doesn’t return Option/Result

Pitfall 4: Assuming None == null for interop

Best Practices

Real-World Example

Further Reading

Exercises

Exercise 1: Safe division

Exercise 2: A combinator pipeline

Exercise 3: ? through nested optional data

Summary

`Option<T>` is just an enum

The `?` operator with `Option`

Borrowing the inner value: `as_ref` and `as_deref`

Pitfall 1: Calling a method on the `Option` instead of the inner value

Pitfall 2: Reaching `unwrap()` for “I know it’s there”

Pitfall 3: Using `?` in a function that doesn’t return `Option`/`Result`

Pitfall 4: Assuming `None == null` for interop

Exercise 3: `?` through nested optional data