Respuesta.

Historia de la pregunta

La coincidencia de patrones es uno de los mecanismos de lenguaje más importantes en Rust, proveniente de los lenguajes funcionales. Permite descomponer de forma declarativa, concisa y segura variantes complejas de valores, incluso con condiciones adicionales (expresiones guard), lo que proporciona flexibilidad y control sobre la lógica.

Problema

Sin la verificación de exhaustividad, parte del potencial de coincidencia de patrones puede implementarse con errores. Además, sin entender el orden de las ramas y las expresiones guard se puede errar en la lógica o en el rendimiento.

Solución

En Rust, el compilador verifica que todas las variantes de enum (o estructuras de patrón más simples) están descompuestas, o que hay una rama _. La rama puede estar limitada adicionalmente por una expresión guard (if después del patrón), y solo se "activa" si se cumple la condición. Las variantes restantes no se capturan. El orden de las ramas es importante: se verifican de arriba hacia abajo.

Ejemplo de código:

enum Message {
    Hello,
    Data(i32),
    Quit,
}

fn handle(msg: Message) -> &'static str {
    match msg {
        Data(n) if n > 10 => "Big Data",
        Data(_) => "Some Data",
        Hello => "Greet!",
        Quit => "Bye",
    }
}

Características clave:

Seguridad gracias a la verificación de exhaustividad: el compilador no permitirá omitir casos (o forzará a poner explícitamente '_').
Posibilidad de usar expresiones guard para ampliar las condiciones de procesamiento.
Las ramas se verifican en orden de arriba hacia abajo, el primer patrón+guard coincidente se activa.

Preguntas engañosas.

¿Se activa la rama con guard si el patrón coincide, pero la condición no se cumple?

No, en tal caso, la verificación pasa a la siguiente rama adecuada. Patrón + guard es un "filtro" atómico; solo cuando ambos coinciden, se ejecuta el cuerpo de la rama.

¿Influye el orden de las ramas en el match sobre el rendimiento?

Sí. Especialmente con una abundancia de patrones similares con guard: el compilador verifica las ramas de arriba hacia abajo, lo que influye en la velocidad de verificación en tiempo de ejecución; los valores más frecuentes deben manejarse primero.

¿Se puede omitir la verificación de exhaustividad poniendo solo la rama _?

Técnicamente sí — es permitido, pero se pierde confiabilidad: si el tipo excluye (o añade) nuevos elementos, el compilador no advertirá sobre casos no considerados. Es mejor siempre manejar explícitamente los importantes, y "_" solo en casos extremos.

Errores comunes y antipatrón

Uso de guard sin darse cuenta de que el patrón aparentemente coincide, pero la condición no pasó: casos no considerados.
Ignorar el orden de las ramas en patrones ambiguos, lógica incorrecta.
Siempre es recomendable descomponer enums exhaustivamente, sin volcar todo en "_".

Ejemplo de la vida real

Caso negativo

Código match para enum con expresiones guard, donde el patrón con guard va al final, pero la mayoría de los valores pasa directamente por la primera rama _, y nunca llega al procesamiento necesario.

Pros:

Implementación rápida de un "tapón" en forma de _.

Contras:

La lógica no funciona, los valores necesarios no se capturan, y el código es difícil de probar.

Caso positivo

Primero se enumeran las variantes más comunes e importantes (con guard), y luego se cubren exhaustivamente las restantes — sin código extra en "_".