063: Monad Transformers

The Problem This Solves

fn find_user(id: i32) -> Result<Option<User>, DbError> { ... }
fn find_email(user: &User) -> Result<Option<String>, DbError> { ... }

// Composing them is a nightmare:
fn get_user_email(id: i32) -> Result<Option<String>, DbError> {
 match find_user(id) {
     Err(e) => Err(e),
     Ok(None) => Ok(None),
     Ok(Some(user)) => match find_email(&user) {
         Err(e) => Err(e),
         Ok(None) => Ok(None),
         Ok(Some(email)) => Ok(Some(email)),
     },
 }
}

The Intuition

• `Result<T, E>` adds "can fail with an error"
• `Option<T>` adds "might be absent"
• `Result<Option<T>, E>` stacks both: can fail hard or find nothing

OptionT<E, A> = Result<Option<A>, E>

bind(m, f):
 Err(e)    → Err(e)        ← propagate hard error
 Ok(None)  → Ok(None)      ← propagate soft absence
 Ok(Some a)→ f(a)          ← continue with value

How It Works in Rust

// Step 1: The type alias — OptionT is just Result<Option<A>, E>
type OptionT<A, E> = Result<Option<A>, E>;

// Step 2: The three fundamental operations
mod option_t {
 // Return a value — wraps in Some and Ok
 pub fn pure<A, E>(a: A) -> Result<Option<A>, E> { Ok(Some(a)) }

 // Return "not found" — Ok but None
 pub fn none<A, E>() -> Result<Option<A>, E> { Ok(None) }

 // bind: the key operation — threads through all three cases
 pub fn bind<A, B, E>(
     m: Result<Option<A>, E>,
     f: impl FnOnce(A) -> Result<Option<B>, E>,
 ) -> Result<Option<B>, E> {
     match m {
         Err(e)       => Err(e),     // hard error: propagate up
         Ok(None)     => Ok(None),   // soft absence: propagate up
         Ok(Some(a))  => f(a),       // success: continue with a
     }
 }

 // Lift a Result<A, E> into OptionT — wraps Ok(a) in Some
 pub fn lift_result<A, E>(r: Result<A, E>) -> Result<Option<A>, E> { r.map(Some) }

 // Lift an Option<A> into OptionT — wraps it in Ok
 pub fn lift_option<A, E>(o: Option<A>) -> Result<Option<A>, E> { Ok(o) }
}

// Step 3: Database functions that return OptionT
fn find_user(id: i32) -> Result<Option<String>, String> {
 if id > 0  { Ok(Some(format!("User_{}", id))) }   // found
 else if id == 0 { Ok(None) }                       // not found (soft)
 else       { Err("Invalid ID".into()) }            // error (hard)
}

fn find_email(name: &str) -> Result<Option<String>, String> {
 match name {
     "User_1" => Ok(Some("user1@example.com".into())),  // found
     "User_2" => Ok(None),                               // no email on record
     _        => Err("DB connection failed".into()),     // hard error
 }
}

// Step 4: Using bind for composition — explicit transformer style
fn get_user_email(id: i32) -> Result<Option<String>, String> {
 option_t::bind(
     find_user(id),         // Step 1: find user
     |name| find_email(&name),  // Step 2: find email (only if user found)
 )
 // No nested match — bind handles the three cases automatically
}

get_user_email(1);   // Ok(Some("user1@example.com"))
get_user_email(0);   // Ok(None)  — user not found (soft)
get_user_email(-1);  // Err("Invalid ID")  — hard error

// Step 5: Idiomatic Rust — same result, cleaner syntax
fn get_user_email_idiomatic(id: i32) -> Result<Option<String>, String> {
 // ? handles Err propagation (the "hard failure" case)
 let user = match find_user(id)? {     // ? propagates Err
     Some(u) => u,
     None    => return Ok(None),        // explicit: propagate "not found"
 };
 find_email(&user)
 // Both versions produce identical results — the idiomatic one is usually preferred
}

// Step 6: map — transform the inner value without unwrapping
fn map<A, B, E>(m: Result<Option<A>, E>, f: impl FnOnce(A) -> B) -> Result<Option<B>, E> {
 match m {
     Err(e)      => Err(e),
     Ok(None)    => Ok(None),
     Ok(Some(a)) => Ok(Some(f(a))),  // apply f only to the Some value
 }
}

// Usage:
let upper = map(get_user_email(1), |s| s.to_uppercase());
// Ok(Some("USER1@EXAMPLE.COM"))

What This Unlocks

• Principled error layering — when a computation has exactly two failure modes (hard error + soft absence), `Result<Option<T>, E>` is the right type, and `bind`/`map` make composition clean without nested matches.
• Understanding `?` — the `?` operator is sugar for the `Err` arm of `bind`. Knowing transformer `bind` explains why `?` works, and why you need an explicit `return Ok(None)` for the `None` arm.
• Scaling up — if you need three stacked effects (state + error + logging), formal transformers become unwieldy and Rust's custom error enum with `?` wins. Understanding transformers shows exactly where that threshold is.

Key Differences