match exhaustivo: extraer datos y blindar el futuro

Un enum guarda sus datos bajo llave: la x de un Move no existe hasta que confirmas que estás ante un Move. match es la llave. Y trae una exigencia que al principio irrita y luego adoras: tienes que contemplar todas las variantes. Esa obligación, la exhaustividad, es lo que transforma “añadir un caso nuevo” de una fuente silenciosa de bugs en una lista de errores de compilación que te lleva de la mano.

Abrir el enum y sacar los datos

match compara un valor contra una serie de patrones y, al encajar uno, desestructura: liga los datos internos de la variante a nombres que puedes usar en esa rama. Es una expresión, no una sentencia, así que devuelve un valor:

fn describe(m: &Message) -> String {
    match m {
        Message::Quit => "cerrar".to_string(),
        Message::Move { x, y } => format!("mover a ({x}, {y})"),
        Message::Write(texto) => format!("escribir: {texto}"),
        Message::ChangeColor(r, g, b) => format!("color #{r:02x}{g:02x}{b:02x}"),
    }
}

En Message::Move { x, y }, los nombres x e y no vienen de fuera: los crea el patrón al abrir la variante, y solo viven dentro de esa rama. Cada brazo del match es la única región del programa donde los datos de esa variante son accesibles. El acceso y la comprobación de la variante son el mismo acto: no hay forma de leer la x sin haber demostrado antes que esto es un Move.

La exhaustividad no se negocia

Prueba a olvidar un caso. El compilador no lo perdona:

fn area(s: &Shape) -> f64 {
    match s {
        Shape::Circle { radius } => std::f64::consts::PI * radius * radius,
        Shape::Rectangle { width, height } => width * height,
        // falta Triangle
    }
}

error[E0004]: non-exhaustive patterns: `&Shape::Triangle { .. }` not covered

No es pedantería: es el corazón del asunto. Un match que no cubre todas las variantes es un programa que no ha decidido qué hacer en un caso que puede ocurrir. En otros lenguajes eso se cuela como un switch sin default, un if sin else, y explota en ejecución meses después. Rust convierte ese agujero en un error de compilación antes de que exista.

flowchart TD
A[Anado una variante al enum] --> B[Compilo]
B --> C{Todos los match la cubren}
C -->|no| D[Error E0004 por cada match incompleto]
D --> E[El compilador lista donde decidir]
E --> F[Reviso caso por caso]
C -->|si| G[Compila, ningun caso olvidado]
F --> G
style D fill:#f38ba8,color:#11111b
style G fill:#a6e3a1,color:#11111b

El compilador como lista de tareas

Aquí está el verdadero regalo de la exhaustividad, y solo se ve cuando el código evoluciona. Imagina que meses después el dominio crece y añades una variante:

enum Shape {
    Circle { radius: f64 },
    Rectangle { width: f64, height: f64 },
    Triangle { base: f64, height: f64 },
    Ellipse { a: f64, b: f64 },   // nueva
}

En cuanto recompilas, todos los match sobre Shape que no contemplen Ellipse se encienden en rojo, uno por uno:

error[E0004]: non-exhaustive patterns: `&Shape::Ellipse { .. }` not covered
  --> src/geometria.rs:12:11
error[E0004]: non-exhaustive patterns: `&Shape::Ellipse { .. }` not covered
  --> src/render.rs:47:11
error[E0004]: non-exhaustive patterns: `&Shape::Ellipse { .. }` not covered
  --> src/serializar.rs:88:11

El compilador te entrega la lista exacta de sitios que tienes que revisar para que el cambio sea correcto. No hay que recordarlos, ni buscarlos con grep, ni rezar por la cobertura de tests. Refactorizar un tipo central deja de dar miedo porque el compilador te acompaña hasta el último rincón afectado.

Cuando solo te importa un caso

Un match completo es excesivo si solo actúas ante una variante. Para eso está if let, y su pareja let ... else para el camino feliz:

// if let: actua solo si encaja, con else opcional
if let Message::Write(texto) = &msg {
    println!("hay texto: {texto}");
}

// let-else: extrae o abandona (return, break, panic) en el camino de error
fn primer_char(m: &Message) -> char {
    let Message::Write(texto) = m else {
        return '?';   // no era Write: salimos ya
    };
    texto.chars().next().unwrap_or('?')  // aqui texto ya esta ligado
}

let ... else es especialmente valioso: extrae los datos al hilo principal de la función (sin anidar un bloque), y obliga a que la rama else diverja (return, break, panic!). Es el patrón idiomático para “dame el dato o lárgate”, y mantiene el código plano en lugar de una escalera de if let anidados.

match es una expresión, no una sentencia

En Rust match no ejecuta ramas: evalúa a un valor, y por eso puede estar a la derecha de un =. Todas las ramas deben producir el mismo tipo, y esa restricción se alía con la exhaustividad:

enum Semaforo { Rojo, Ambar, Verde }

fn instruccion(s: Semaforo) -> &'static str {
    let etiqueta = match s {
        Semaforo::Rojo => "detente",
        Semaforo::Ambar => "precaución",
        Semaforo::Verde => "avanza",
    };            // etiqueta: &str, decidido por el match completo
    etiqueta
}

Piensa en la consecuencia de diseño: como el match entero es una expresión de un solo tipo, no puedes “olvidar” devolver algo en una rama sin que el compilador lo note, ni dejar un caso sin cubrir sin que estalle E0004. Ser expresión y ser exhaustivo se refuerzan mutuamente: cubres todos los casos y cada uno produce el valor. Un if sin else no puede ser una expresión con valor; un match siempre lo es, precisamente porque siempre es total. Esta es la razón profunda de por qué en Rust idiomático casi no ves asignaciones a variables sin inicializar seguidas de un switch que las rellena: el match devuelve el valor de una vez.