Bloques, el tipo unit y el tipo never

Cerramos el control de flujo mirando la maquinaria de tipos que lo sostiene. Un bloque { } es una expresión que vale su última línea. Cuando no hay nada útil que devolver, aparece el tipo unit (). Y cuando una expresión nunca devuelve —un panic!, un return, un loop sin fin— su tipo es el enigmático never, escrito !. Estos dos tipos, uno con un solo valor y otro con ninguno, son las piezas que hacen que toda la orientación a expresiones de Rust encaje sin fisuras.

El bloque es una expresión

Un bloque delimitado por llaves no es solo una agrupación de sentencias: es una expresión cuyo valor es el de su última expresión sin punto y coma. Puedes usarlo para dar un scope acotado a cálculos intermedios y devolver solo el resultado:

let y = {
    let x = 3;
    x * x + 1     // sin `;`: este es el valor del bloque
};
println!("{y}"); // 10

x vive únicamente dentro del bloque; fuera solo sobrevive y. Es el mismo mecanismo por el que el cuerpo de una función devuelve su última expresión sin return, o por el que las ramas de un if “valen” algo. Un bloque que termina en ;, o que está vacío, no devuelve nada útil: vale ().

Esto convierte al bloque en una herramienta de composición: encapsulas varios pasos y usas el resultado justo donde iría un solo valor, sin ensuciar el scope exterior con variables auxiliares que ya no necesitas.

let area = {
    let base = 4.0;
    let altura = 3.0;
    base * altura / 2.0   // el bloque entero "vale" 6.0
};

El tipo unit: ()

() es a la vez un tipo y su único valor. Se le llama unit, y representa “aquí no hay información útil que transmitir”. Aparece por todas partes en cuanto sabes verlo:

fn saludar() {          // sin `-> ...`: devuelve () implícitamente
    println!("hola");   // println! evalúa a ()
}

let nada: () = saludar(); // el valor de retorno ES ()
let a = {};               // un bloque vacío vale ()
let b = { 5; };           // termina en `;`, así que también vale ()

Una función sin tipo de retorno explícito devuelve (). Una sentencia produce (). Poner ; a una expresión descarta su valor y deja (). No es un caso especial ni un “null”: es un tipo normal, con exactamente un habitante, y de tamaño cero en memoria. Por eso Result<(), Error> es idiomático: “esto puede fallar, y si sale bien no hay nada que devolver, solo el hecho de haber salido bien”.

Que () ocupe cero bytes tiene consecuencias reales de diseño: un HashSet<T> de la librería estándar no es más que un HashMap<T, ()> cuyo valor no gasta ni un byte. El () marca “esta clave está presente” sin almacenar nada junto a ella.

El tipo never: !

Ahora el opuesto. Algunas expresiones no se evalúan a ningún valor porque nunca terminan de la forma normal: transfieren el control a otro sitio y no vuelven. Su tipo es !, el tipo never:

fn siempre_falla() -> ! {   // el `-> !` promete: esta función no retorna
    panic!("algo va muy mal");
}

fn bucle_eterno() -> ! {
    loop { /* nunca hay break */ }
}

Tienen tipo !, entre otras, las expresiones panic!(), return, break, continue, std::process::exit(), y los marcadores todo!() y unreachable!(). Todas comparten una propiedad: el código que las sigue en secuencia es inalcanzable, porque el control ya se marchó a otra parte.

Lo fascinante de ! es que encaja como cualquier tipo. Como una expresión de tipo ! no produce ningún valor, el compilador puede tratarla como si fuese del tipo que haga falta en ese contexto, sin peligro. Esto es lo que permite mezclar una rama que devuelve un valor con otra que diverge:

let config: Option<i32> = None;
let valor: i32 = match config {
    Some(v) => v,            // esta rama vale i32
    None => panic!("falta"), // esta vale !, y ! encaja como i32
};

Sin esta regla, cada match con un panic! o un return en una rama fallaría por “tipos incompatibles”. Gracias a ella, divergir es siempre compatible con cualquier tipo esperado.

Divergir en la práctica

Esta compatibilidad universal de ! no es un tecnicismo académico: es lo que hace que los patrones de salida temprana se compongan sin fricción. El let-else de la lección anterior obliga a que su bloque else diverja precisamente porque su tipo ha de ser !; así el compilador sabe que, si la ejecución continúa, el valor quedó ligado.

fn primer_par(nums: &[i32]) -> i32 {
    let Some(&x) = nums.iter().find(|n| *n % 2 == 0) else {
        return -1; // el else diverge: su tipo es !
    };
    x // aquí x existe con seguridad
}

Lo mismo sostiene a los métodos de Option y Result que verás pronto: unwrap, expect y el operador ? se apoyan en que panic! y return tengan tipo ! para encajar en cualquier expresión sin estropear la inferencia de tipos.

let cfg = leer_config().expect("config ilegible");
// expect() devuelve el valor interior o diverge: su tipo encaja como T

Y observa el contraste final entre los dos tipos como retorno: una función que devuelve () termina y no dice nada; una que devuelve ! no termina en absoluto. Son los dos extremos de cuánta información sale de una llamada: ninguna útil, o literalmente ninguna.

fn registra(msg: &str) {       // -> () implícito: termina, sin valor
    println!("[log] {msg}");
}

fn aborta(codigo: i32) -> ! {  // -> !: no vuelve jamás
    std::process::exit(codigo);
}

flowchart LR
U[unit parentesis vacio] -->|exactamente un valor| I[Tipo habitado]
N[never signo de cierre] -->|cero valores| V[Tipo vacio]
V -->|encaja como cualquier tipo| Any[i32 String bool y mas]
style U fill:#89b4fa,color:#11111b
style N fill:#f38ba8,color:#11111b
style Any fill:#a6e3a1,color:#11111b