Desenvolver Option con seguridad: de match a los métodos

Tener un Option<T> es tener una promesa a medias: quizá haya un T, quizá no. Desenvolverlo es cobrar esa promesa, y hay dos maneras de hacerlo: la honesta, que contempla el vacío, y la temeraria, que apuesta a que nunca ocurrirá y hace panic! si pierde. Rust te da ambas a propósito, pero la frontera entre “cómodo” y “código que revienta en producción” pasa justo por aquí. Aprender a desenvolver bien es aprender a no reintroducir el null que Option acababa de matar.

match e if let: el control total

Las herramientas de 6.2 se aplican tal cual a Option, porque Option no es más que un enum. match te obliga a cubrir los dos casos y desestructura el valor en la rama Some:

fn saludo(nombre: Option<&str>) -> String {
    match nombre {
        Some(n) => format!("Hola, {n}"),
        None => "Hola, desconocido".to_string(),
    }
}

Cuando solo te importa el caso con valor, if let evita el ceremonial, y let ... else extrae al hilo principal de la función obligando a que el camino vacío diverja:

if let Some(n) = nombre {
    println!("hay nombre: {n}");
}

fn inicial(nombre: Option<&str>) -> char {
    let Some(n) = nombre else {
        return '?';              // sin nombre: salimos ya
    };
    n.chars().next().unwrap_or('?')
}

Esto siempre es correcto porque nunca ignora el None. El resto de la lección son atajos: azúcar sobre este match, con distintos compromisos.

La familia unwrap: atajos con precio

A veces escribir un match de dos ramas para un caso trivial es ruido. La biblioteca estándar ofrece métodos que colapsan ese match en una llamada. La diferencia entre ellos es qué hacen con el None:

En código:

let x: Option<i32> = Some(5);
let vacio: Option<i32> = None;

x.unwrap();                       // 5
x.expect("x debería venir del parser");   // 5, con mensaje si fallara
vacio.unwrap_or(0);               // 0
vacio.unwrap_or_else(|| calculo_caro());  // llama al closure solo aquí
vacio.unwrap_or_default();        // 0, el Default de i32

Ansioso frente a perezoso

unwrap_or y unwrap_or_else parecen intercambiables, pero esconden una diferencia que importa. El argumento de unwrap_or se evalúa antes de la llamada, exista o no el valor; el de unwrap_or_else solo se evalúa si el Option es None:

// Si el Option es Some, la conexión se abre EN VANO y se descarta.
let cfg = opcion.unwrap_or(abrir_conexion_por_defecto());

// La conexión solo se abre cuando de verdad falta el valor.
let cfg = opcion.unwrap_or_else(|| abrir_conexion_por_defecto());

Regla práctica: si el defecto es un literal o algo baratísimo (0, "", un Vec::new), usa unwrap_or por legibilidad. Si construirlo tiene coste o efectos secundarios —abrir un fichero, reservar memoria, consultar la red— usa unwrap_or_else y paga solo cuando toca. Para el valor por defecto del tipo, unwrap_or_default es el atajo idiomático.

Por qué unwrap es un olor de código

unwrap y expect no manejan el None: lo convierten en un panic! que aborta el hilo. Es decir, cogen la ausencia que Option te obligaba a considerar y la transforman de nuevo en un fallo de ejecución —exactamente el billón de dólares que 7.1 acababa de desterrar—. Por eso, en código de biblioteca o de producción, cada unwrap es una deuda: una afirmación no demostrada de que “aquí nunca será None”.

Esto no significa que estén prohibidos. Son perfectamente legítimos en:

• prototipos y borradores, donde quieres avanzar y ya endurecerás luego;
• ejemplos y documentación, donde el match distraería del punto;
• tests, donde un None inesperado debe hacer fallar el test ruidosamente;
• invariantes de verdad imposibles, y ahí siempre expect con un mensaje que explique por qué es imposible, nunca unwrap a secas.

flowchart TD
A[Tengo un Option y necesito el valor] --> B[Debo actuar en los dos casos]
B --> M[match exhaustivo]
A --> C[Solo me importa el caso con valor]
C --> L[if let o let else]
A --> D[Quiero un valor por defecto si falta]
D --> E[unwrap_or o unwrap_or_else]
A --> F[Garantizo que jamas sera None]
F --> G[expect con la invariante documentada]
style M fill:#a6e3a1,color:#11111b
style L fill:#89b4fa,color:#11111b
style E fill:#f9e2af,color:#11111b
style G fill:#f38ba8,color:#11111b