Option Combinators

You receive an optional username from a query string and need its length. The first version every Rust programmer writes is this:

let name: Option<&str> = get_query("user");

let len = match name {
    Some(n) => Some(n.trim().len()),
    None => None,
};

It is correct and it is also four lines of scaffolding for one transformation. map does exactly what that match did — apply a function to the value inside Some, and leave None untouched — in one expression:

let len = name.map(|n| n.trim().len());   // Option<usize>

let greeting = name.map(|n| format!("hello, {n}"));  // Option<String>

The signature is the whole mental model:

fn map<U, F>(self, f: F) -> Option<U> where F: FnOnce(T) -> U

Some(x) becomes Some(f(x)); None stays None; the function never runs in the None case. Note that the output type U is free — map is how Option<T> changes type, not just value: Option<&str> in, Option<usize> out, with no unwrap, no panic, and no branch written by you.

Three facts separate map from a naive match rewrite:

1. It is eager, not lazy. Unlike iterator adapters, Option combinators run immediately — there is no underlying stream to defer work to. opt.map(expensive()) computes expensive() right now, only skipping it when the option is None.
2. It consumes self. After name.map(...), name has been moved, so the classic beginner error is:

let name: Option<String> = Some("ada".into());
let upper = name.map(|s| s.to_uppercase());
println!("{name:?}");   // error[E0382]: borrow of moved value: `name`

If you need the original afterwards, work on a copy: name.as_ref().map(...) borrows, or name.clone().map(...) for owned data. Option<&str> and Option<usize> are Copy, so they survive — which is why the bug appears only once your option holds a String.
3. There is a three-argument sibling. map_or(default, f) applies f on Some and yields default on None:

let status = code.map_or("unknown".to_string(), |c| format!("HTTP {c}"));

When the default itself costs work — a file read, an allocation, a query — map_or_else(f_default, f) takes closures for both sides so nothing runs until needed.

Where this shows up in real code: HTTP headers (headers.get("content-length").map(|v| v.parse::<u64>().ok())), HashMap::get(...).map(...), env::var("HOME").map(PathBuf::from), and slice.first().map(...). Every one of them is a value you might not have, plus a transformation you want only if you do.

The map family is small, and knowing all four members keeps you from hand-writing branches:

Note the last row already hints at the failure case: if f can itself return nothing, map gives you the wrong shape and and_then takes over — the subject of the next chapter.

A realistic body reads like a pipeline of facts rather than a nest of branches. Converting an optional query parameter into a page size:

let page_size = query
    .get("limit")
    .and_then(|v| v.parse::<usize>().ok())   // String -> Option<usize>
    .map(|n| n.clamp(1, 100))                // sanitize only if present
    .unwrap_or(20);                          // default when absent

Three combinators and one default, no match, no unwrap, and the policy (clamp, then default) is visible in the order of the calls.

The match is still the right tool when the None arm does something different in kind — logging, falling back to a computed value, or deciding control flow. map is for the case where both arms produce the same shape and only the payload differs. The next chapter covers the harder case: when the transformation itself can fail, and map starts wrapping failure inside Some instead of keeping it out.

map breaks the moment the transformation can fail. Parse a port string into a number and you get Option<Result<u16, _>> — failure nested inside success, a shape no caller wants to unwrap twice:

let raw: Option<&str> = env::var("PORT").ok();
let parsed = raw.map(|s| s.parse::<u16>());   // Option<Result<u16, ParseIntError>>

and_then is the fix: it takes a closure that returns an Option and flattens the result instead of nesting it, because the closure already did the branching for you.

let port: Option<u16> = raw.and_then(|s| s.parse::<u16>().ok());

Some("8080") → closure returns Some(8080) → Some(8080). Some("eighty") → closure returns Err, .ok() turns it into None → None. None → closure never runs → None. One flat type at every step, which is why and_then is often called the monadic bind of Option — the operation that lets you sequence partial computations without writing the None check yourself.

fn header_len(req: Option<Request>) -> Option<usize> {
    req.and_then(|r| r.headers.get("content-length"))
        .and_then(|v| v.to_str().ok())
        .and_then(|s| s.parse::<usize>().ok())
}

Each step can produce nothing, and you never mention None in the body. This is the shape you reach for whenever a pipeline has any fallible stage — and it is the same idea as ? on Result, which is why The question mark Operator feels immediately familiar after this clicks.

When the closure returns a Result, flatten it with .ok() (drop the error) or keep the error by switching to Result combinators. The common intermediate pattern when you want both the value and the error later:

let port: Result<u16, ParseIntError> = raw
    .ok_or("PORT missing")            // Option -> Result
    .and_then(|s| s.parse().map_err(|_| "PORT is not a number"));

A rule that prevents the double-wrap bug: map may wrap an error in Some; and_then must not. If your closure's return type starts with Option or Result, you wanted and_then. If it returns a plain value, you wanted map. Compiler error expected u16, found Option<u16> at the use site is the tell-tale sign you picked the wrong one — and Option::flatten exists for the rare case where you already produced the nested shape and want to collapse it (Option<Option<T>> → Option<T>).

Two standard-library helpers exist for the nesting mess once you have it, and they are worth memorizing because they appear in other people's code:

let maybe: Option<Result<u16, _>> = raw.map(|s| s.parse::<u16>());

let flat: Option<u16> = maybe.and_then(Result::ok);            // drop the error
let as_result: Result<Option<u16>, _> = maybe.transpose();     // Option<Result<T,E>> -> Result<Option<T>,E>

flatten only collapses Option<Option<T>> — it is the wrong tool for this shape. transpose is the one you actually need: it moves the failure out of the option so ? can propagate it while the absence stays an Option — exactly the mixed situation you get when a lookup may legitimately return nothing but a value, once found, must parse. The three-way matrix — map (wrap), and_then (splice), transpose (reorder) — is the complete toolbox for Option/Result nesting.

Chains evaluate left to right and stop at the first None, so they short-circuit exactly like ?: no later closure runs, no later allocation happens. That makes a long and_then chain both readable and cheap — the failing step is the last one that executed, which is precisely the information you need when debugging a pipeline that "returns None somewhere."

After the value is transformed and chained, the last question is usually "what do I use if it is None?" Rust gives you three tiers of answer, and the tier you pick decides whether your program panics, allocates, or stays silent.

let count: Option<usize> = cache.get("hits");

count.unwrap()                    // panics on None — the thing we are avoiding
count.unwrap_or(0)                // literal default, zero cost
count.unwrap_or_else(|| load_default_from_disk())  // default computed only if None
count.unwrap_or_default()         // Default::default() — 0 for numbers, "" for String, Vec::new()

The distinction that shows up in performance reviews: unwrap_or takes a value, so it is evaluated eagerly. cache.len().unwrap_or(expensive_rebuild()) rebuilds even when the option is Some. unwrap_or_else takes a closure and defers it, which is the right default for anything heavier than a constant. unwrap_or_default is the sugar for the extremely common case where Default already encodes the sensible answer.

Two subtler combinators finish the toolkit:

filter is the one people forget, and it reads beautifully on real data:

let admin = users.iter()
    .find(|u| u.name == "root")
    .filter(|u| u.is_active)
    .map(|u| u.last_login);

Without filter you are back to match with two conditions; with it, the predicate stays a predicate. Another idiom: filter plus is_some() as a boolean guard — config.get("telemetry").filter(|v| v == "on").is_some() — reads as "present and enabled" with no nesting.

Watch the ownership trap that catches everyone once: unwrap_or moves the option's contents, so this does not compile:

let label: Option<String> = load_label();
let text = label.clone().unwrap_or_else(|| "anonymous".into());
println!("{label:?}");   // error: borrow of moved value

Clone, or take as_ref() first when you only need a borrowed default.

The interview framing for this whole topic: someone will ask you to "handle a missing value without unwrap," and the correct answer is a gradient — map to transform, and_then to chain fallible steps, filter to reject, and unwrap_or_else/unwrap_or_default to supply a fallback, with match reserved for when the None branch does something structurally different. Every one of those keeps the failure out of the panic path — the policy argued in unwrap, expect, and When Panics Are Acceptable — which is the same discipline that makes the ? operator in the next topic productive.

A worked example combining every combinator in this topic, the shape you will recognize in production code:

fn render(req: &Request) -> String {
    req.headers.get("x-request-id")           // Option<&String>
        .filter(|id| !id.is_empty())          // reject the empty-header case
        .map(|id| id.trim().to_owned())       // String, owned for the log line
        .unwrap_or_else(|| Uuid::new_v4().to_string())   // costly fallback, only on None
}

Read the decisions it encodes: presence is optional, emptiness is rejected, normalization happens before the default can mask it, and the expensive UUID generation is deferred to the branch that needs it. Swap unwrap_or_else for unwrap_or and you pay for a UUID on every request — the kind of regression that shows up in a profile, not in a compiler error.