Option: la ausencia de valor sin null

Casi todos los lenguajes tienen un valor que significa “nada” y que cabe en cualquier hueco: null, nil, None, el puntero cero. Es tan cómodo como letal, porque miente sobre el tipo: una variable que dice contener un Usuario puede en realidad no contener nada, y nadie te obliga a comprobarlo. Rust toma la decisión más radical de su diseño de tipos: el null no existe. La ausencia legítima se modela con un enum normal y corriente —Option<T>— y el compilador no te deja mirar dentro sin haber contemplado antes el vacío.

El error del billón de dólares

En 1965 Tony Hoare añadió la referencia nula a ALGOL W “simplemente porque era fácil de implementar”. Cuarenta años después la bautizó, sin ironía, como my billion-dollar mistake: el coste acumulado de todas las caídas y agujeros de seguridad que esa idea sembró. El problema no es el valor nulo en sí, sino que en la mayoría de lenguajes todo tipo lo admite en silencio. Un String de Java es en realidad “un String o una bomba”; el *p de C reza por que p no sea NULL. El tipo promete algo que el lenguaje no garantiza, y la mentira se cobra en ejecución, lejos del sitio donde se coló el vacío.

Rust deshace el nudo: no hay palabra null, ni referencia nula, ni valor vacío implícito. Una &T apunta siempre a un T válido; un String contiene siempre una cadena. Si algo puede faltar, ese “puede faltar” tiene que aparecer, explícito, en el tipo.

Option: la ausencia como un enum más

Aquí no hay magia. Option<T> es exactamente el tipo suma que construiste en 6.1, con dos variantes y genérico sobre T:

enum Option<T> {
    None,
    Some(T),
}

Some(valor) envuelve un valor presente; None es la ausencia. Ambas están en el preludio, así que las usas sin importar nada. Una función que quizá no tenga respuesta lo declara en su tipo de retorno:

fn primer_par(v: &[i32]) -> Option<i32> {
    for &x in v {
        if x % 2 == 0 {
            return Some(x);   // encontrado
        }
    }
    None                      // recorrimos todo sin éxito
}

let a = primer_par(&[1, 3, 4, 7]);   // Some(4)
let b = primer_par(&[1, 3, 5]);      // None

Y leerlo es aplicar lo de 6.2 sin ninguna regla nueva: un match que contempla, obligatoriamente, las dos variantes.

match primer_par(&[1, 3, 4, 7]) {
    Some(par) => println!("el primer par es {par}"),
    None => println!("no había ningún par"),
}

La ausencia dejó de ser un fantasma escondido dentro de i32 y pasó a ser una variante visible en la firma. Media biblioteca estándar habla este idioma: slice::first, HashMap::get, str::parse, Iterator::next devuelven todos Option, porque todos describen operaciones que legítimamente pueden no dar nada.

El compilador no te deja leer el vacío

Esta es la diferencia que lo cambia todo. Option<i32> no es i32; son tipos distintos, y no puedes tratar uno como el otro:

let n: Option<i32> = primer_par(&[1, 3, 4]);
// let doble = n * 2;

error[E0369]: cannot multiply `Option<i32>` by `{integer}`

Para llegar al i32 de dentro estás obligado a abrir el Option con las herramientas de 6.2 —match, if let, let ... else— o con los métodos que verás en 7.2, y en todos los casos tienes que decir explícitamente qué ocurre cuando es None. El caso vacío es imposible de olvidar porque está grabado en el tipo: si no lo contemplas, el programa no compila. Compáralo con el null, donde olvidar la comprobación es lo normal y el castigo llega meses después, en producción.

Y como viste en 6.1, esta seguridad no cuesta memoria: gracias a la optimización de nicho, Option<&T> ocupa lo mismo que un puntero desnudo, porque el patrón nulo —que una & jamás toma— se reserva para None. Obtienes la representación de C con la garantía que C nunca dio.

flowchart TD
A[Funcion que quiza no tenga valor] --> B[Tipo de retorno Option de T]
B --> S[Some con el valor dentro]
B --> N[None: ausencia explicita y tipada]
S --> E[El compilador exige abrir el Option]
N --> E
E --> F[Imposible usar el vacio por accidente]
style B fill:#cba6f7,color:#11111b
style S fill:#a6e3a1,color:#11111b
style N fill:#f9e2af,color:#11111b
style F fill:#89b4fa,color:#11111b

None no es un error

Un matiz que separa a los principiantes de quien piensa en Rust: Option responde a la pregunta “¿hay un valor?”, no a “¿algo falló?”. Que first() sobre un slice vacío dé None, o que buscar una clave ausente en un HashMap dé None, no es un error: es una respuesta perfectamente normal y esperada. El vacío aquí no lleva explicación porque no hace falta ninguna.

use std::collections::HashMap;

let edades = HashMap::from([("ana", 30)]);
let ana: Option<&i32> = edades.get("ana");    // Some(&30)
let juan: Option<&i32> = edades.get("juan");  // None: ausencia normal, no un fallo

Cuando la ausencia sí necesita justificarse —por qué no se pudo abrir el fichero, qué campo del formulario estaba mal— None se queda corto, porque no puede transportar el motivo. Ese es el territorio de Result<T, E>, que llega en 7.3: el mismo patrón de “un valor envuelto en un enum”, pero con un canal para el error. Guarda esta frontera: Option es ausencia, Result es fallo con causa.