Elision avanzada: donde el compilador se rinde y te obliga a anotar

Ya sabes que tres reglas mecanicas rellenan los lifetimes omitidos en las firmas y por eso escribes tan pocos. Esta leccion mira el otro lado: los limites de esa maquinaria. La elision es deliberadamente conservadora —solo resuelve lo inequivoco— y hay familias enteras de firmas donde se rinde y te exige la anotacion explicita. Algunas son clasicas (dos entradas prestadas sin self). Otras son sutiles y aparecen al devolver impl Trait, donde la captura de lifetimes cambio de raiz en la edicion 2024. Conocer donde el compilador se detiene te ahorra pelear a ciegas: cuando entiendas por que no puede inferir, sabras al instante que region falta escribir.

Los fallos clasicos: cuando ninguna regla decide

Recuerda las tres reglas: cada entrada recibe un lifetime propio; si hay una sola entrada con lifetime, va a la salida; si hay &self, el de self manda sobre las salidas. Los fallos aparecen justo cuando ninguna de las dos ultimas resuelve la salida.

El caso emblematico es varias entradas prestadas y ningun self: la regla 1 reparte un lifetime distinto a cada entrada, pero la salida se queda huerfana y el compilador aborta con E0106 en vez de adivinar.

fn mas_larga(a: &str, b: &str) -> &str {   // ERROR E0106
    if a.len() >= b.len() { a } else { b }
}
// La cura es tuya: unifica las dos entradas bajo una region comun.
fn mas_larga_ok<'a>(a: &'a str, b: &'a str) -> &'a str {
    if a.len() >= b.len() { a } else { b }
}

El segundo fallo es mas insidioso porque compila pero miente: cuando la regla 3 ata la salida a self y tu en realidad querias atarla a un parametro. La firma pasa, pero encadena la vida del resultado al receptor equivocado.

struct Lexer<'s> { fuente: &'s str }

impl<'s> Lexer<'s> {
    // Elision: la salida se ata a &self, no a `otro`. Puede no ser lo que quieres.
    fn primero(&self, _otro: &str) -> &str { &self.fuente[..1] }

    // Si la salida sale de un PARAMETRO, debes anotarlo a mano para romper la regla 3:
    fn de_otro<'o>(&self, otro: &'o str) -> &'o str { &otro[..1] }
}

Sobreescribir la elision: anotar no es solo para errores

La leccion anterior te enseno que anotas cuando el compilador no puede inferir. Aqui hay un motivo distinto y mas fino: anotar cuando el compilador infiere algo correcto pero demasiado restrictivo. La elision siempre elige la lectura que compila, no la mas flexible. Si aceptas su eleccion por defecto, a veces atas la salida a una region mas corta de lo necesario y rechazas llamadas legitimas aguas arriba.

// Elision: ambos '_ colapsan a la region de &self; el resultado no puede vivir mas que el struct.
// fn ventana(&self) -> &str

// Anotando, separas la region del dato prestado de la del propio receptor:
struct Buffer<'d> { datos: &'d str }
impl<'d> Buffer<'d> {
    // La salida vive tanto como los DATOS ('d), no solo tanto como &self:
    fn ventana(&self) -> &'d str { self.datos }
}

La diferencia es real: con la version elidida, el &str devuelto muere cuando muere el prestamo de self; con -> &'d str, sobrevive mientras vivan los datos originales, aunque el Buffer desaparezca. Anotar aqui no arregla un error: amplia el contrato.

La captura de lifetimes en impl Trait: el gran cambio de 2024

El terreno donde la elision se vuelve mas resbaladiza es el retorno impl Trait (RPIT, return position impl Trait). Un tipo impl Iterator oculto puede capturar lifetimes del entorno, y la pregunta “cuales captura” tuvo dos respuestas distintas segun la edicion.

Antes de 2024, un RPIT capturaba los parametros de tipo en scope pero no los lifetimes, salvo que los mencionaras. Devolver un iterador que prestaba de un argumento fallaba con “hidden type captures lifetime that does not appear in bounds”, y el remedio era el ritual + '_ o el truco del trait Captures.

// EDICION 2024: el RPIT captura por defecto TODOS los parametros en scope, tipos y lifetimes.
fn palabras<'a>(texto: &'a str) -> impl Iterator<Item = &'a str> {
    texto.split(' ')            // captura 'a automaticamente; ya no hace falta el viejo + '_
}

En la edicion 2024 la regla se unifico y simplifico: un RPIT captura todos los parametros genericos en scope, tanto de tipo como de lifetime. Se acabaron los errores de “lifetime no capturado” en el caso normal. Pero el nuevo defecto es mas generoso, y a veces captura de mas: si el tipo oculto no usa realmente cierto lifetime, capturarlo igualmente ata el resultado sin necesidad. Para eso existe la captura precisa con + use<...>, estabilizada en Rust 1.82: enumeras exactamente que parametros quieres capturar.

// El tipo oculto NO usa 'b, pero el defecto de 2024 lo capturaria. use<> lo excluye:
fn solo_a<'a, 'b>(a: &'a str, _b: &'b str) -> impl Iterator<Item = char> + use<'a> {
    a.chars()
}

El caso mas cotidiano de este mecanismo es un metodo que devuelve un iterador prestado de self. Antes de 2024 requeria el ritual + '_ para capturar la region del receptor; en 2024 el defecto ya la captura, y solo tocas use<...> si quieres restringirla.

struct Registro { lineas: Vec<String> }

impl Registro {
    // Edicion 2024: el impl Iterator captura la region de &self por defecto, sin + '_.
    fn no_vacias(&self) -> impl Iterator<Item = &str> {
        self.lineas.iter().map(String::as_str).filter(|s| !s.is_empty())
    }
}

flowchart TB
f[Firma con lifetimes omitidos] --> q1[Varias entradas prestadas y ningun self?]
q1 -->|si| e1[E0106: anota y unifica o separa regiones]
q1 -->|no| q2[La salida sale de self o de un parametro?]
q2 -->|de self| ok[Regla 3: elision correcta]
q2 -->|de un parametro| e2[Anota a mano para romper la regla 3]
f --> q3[Devuelves impl Trait?]
q3 -->|si| cap[Edicion 2024: captura todo en scope; usa use para precisar]