Elisión de lifetimes: las tres reglas que te ahorran escribirlos

Si los lifetimes están en toda referencia, ¿por qué escribes tan pocos? Porque el compilador aplica, sobre las firmas de las funciones, tres reglas de elisión que rellenan los lifetimes evidentes por ti. No son inferencia mágica ni analizan el cuerpo: son tres pasos mecánicos y deterministas que cubren la inmensa mayoría de las firmas reales. Entenderlas te dice exactamente cuándo no tienes que anotar nada —y, más útil aún, cuándo las reglas se quedan cortas y el compilador te exige la anotación explícita.

Las tres reglas

La elisión opera solo sobre lifetimes omitidos en la firma de una función o de un método. El compilador los rellena aplicando en orden estas tres reglas. Si al terminar todos los lifetimes de salida han quedado determinados, la firma compila sin que escribas nada; si alguno queda sin determinar, es un error y debes anotar.

La primera regla reparte lifetimes distintos a cada entrada. La segunda y la tercera son las que resuelven la salida: la segunda cuando solo hay una fuente posible, la tercera cuando el método tiene un receptor self que manda sobre los demás parámetros.

Regla 2 en acción: una sola entrada

El caso más común de todos. Una función con un único parámetro prestado que devuelve una referencia: no hay ambigüedad posible, la salida solo puede salir de esa entrada.

// Lo que escribes:
fn primera_palabra(s: &str) -> &str {
    match s.find(' ') { Some(i) => &s[..i], None => s }
}

// Lo que el compilador razona tras aplicar las reglas 1 y 2:
fn primera_palabra<'a>(s: &'a str) -> &'a str { /* ... */ }

La regla 1 le da a s el lifetime 'a; como es la única entrada con lifetime, la regla 2 asigna 'a a la salida. Firma resuelta, cero anotaciones. Este patrón —tomar una vista, devolver una subvista— es tan frecuente que la elisión lo vuelve invisible.

Regla 3 en acción: métodos con self

En un método, &self casi siempre es la fuente natural de las referencias que devuelves, así que la tercera regla lo prioriza sobre cualquier otro parámetro prestado.

struct Buffer { datos: String }

impl Buffer {
    // Escribes esto:
    fn buscar(&self, patron: &str) -> &str {
        match self.datos.find(patron) {
            Some(i) => &self.datos[i..],
            None => "",
        }
    }
    // El compilador lo lee como:
    // fn buscar<'s, 'p>(&'s self, patron: &'p str) -> &'s str
}

Aunque hay dos entradas prestadas —self y patron—, la regla 3 rompe el empate: la salida se ata a self. Esto es casi siempre lo que quieres, porque los métodos devuelven vistas de su propio contenido, no de sus argumentos.

La regla 3 cubre igual a &mut self: un método que devuelve un &mut de su propio contenido ata la salida a la región del receptor. Es lo que permite escribir getters mutables sin una sola anotación.

struct Pila { items: Vec<i32> }

impl Pila {
    // La regla 3 también gobierna &mut: la salida sale de `self`.
    fn cima_mut(&mut self) -> &mut i32 {
        self.items.last_mut().unwrap()   // -> &'s mut i32 por la regla del self
    }
}

flowchart TB
start[Firma con lifetimes omitidos] --> r1[Regla 1: un lifetime distinto por entrada]
r1 --> hay[Queda alguna salida sin lifetime?]
hay -->|no| ok[Firma resuelta: no anotas]
hay -->|si| r2[Hay una sola entrada con lifetime?]
r2 -->|si| asig1[Regla 2: esa entrada va a la salida]
r2 -->|no| r3[Hay self?]
r3 -->|si| asig2[Regla 3: el self va a la salida]
r3 -->|no| err[Ambiguo: E0106, anota a mano]
asig1 --> ok
asig2 --> ok

Cuándo las reglas fallan

La elisión es deliberadamente conservadora: solo resuelve lo que es inequívoco. En cuanto hay varias entradas prestadas y ningún self, ninguna regla decide de cuál sale la salida, y el compilador se rinde con E0106 en lugar de adivinar. Es el caso de mas_larga:

fn mas_larga(a: &str, b: &str) -> &str {   // ERROR E0106
    if a.len() >= b.len() { a } else { b }
}

La regla 1 da 'a a a y 'b a b. La regla 2 no aplica (hay dos entradas), la regla 3 tampoco (no hay self). La salida se queda huérfana de lifetime, y ahí terminan las reglas: tú debes anotar <'a> y decidir la relación. Que el compilador no adivine es una virtud, no una limitación: adivinar mal ataría la salida a un dato equivocado y escondería un error de vida bajo una firma que compila.

Conviene fijar el alcance de la elisión: actúa en las firmas de funciones y métodos, no en cualquier posición. Los campos de un struct nunca la disfrutan —siempre declaras su lifetime, como viste en la lección 3—, y los ítems static y const que contienen referencias exigen 'static explícito. La elisión es una comodidad para el caso rutinario de las funciones, no una ley universal del lenguaje; fuera de las firmas, sigues escribiendo la región a mano.

'_ y la elisión explícita

A veces quieres señalar que hay un lifetime elidido sin nombrarlo, sobre todo en tipos con lifetime como Parser<'a>. Para eso está '_, el lifetime anónimo: le dice al lector y al compilador “aquí hay una región, deja que la elisión la resuelva”. En Rust 2024 es idiomático y en muchos contextos el lint elided_lifetimes_in_paths te anima a escribirlo.

struct Parser<'a> { input: &'a str }

// `'_` hace visible que Parser lleva un lifetime, resuelto por elisión:
fn crear(texto: &str) -> Parser<'_> {
    Parser { input: texto }
}
// aplicando las reglas: fn crear<'a>(texto: &'a str) -> Parser<'a>

El '_ también aparece en objetos de trait y en tipos con lifetime dentro de rutas: escribir Box<dyn Error + '_> o Ref<'_, T> hace visible que ahí vive una región elidida. En la edición 2024, el estilo idiomático prefiere el '_ explícito a la omisión total, porque le avisa al lector de que el tipo carga un lifetime sin obligarte a bautizarlo. Es la mejor de las dos posturas: la comodidad de no inventar un nombre y la honestidad de no esconder que hay una región en juego.