Lifetimes en structs: cuando un tipo guarda una referencia prestada

Hasta ahora las referencias vivían en variables y firmas. Pero un struct también puede guardar una referencia en un campo, y eso cambia la naturaleza del tipo: deja de ser un dato autónomo y se convierte en una vista atada a otro dato que vive fuera. Rust te obliga a declararlo con un lifetime —struct Parser<'a>—, y esa anotación arrastra una consecuencia inevitable: ninguna instancia del struct puede sobrevivir al dato que tiene prestado.

Un campo referencia obliga a un lifetime

Si un struct contiene una referencia, el compilador exige que declares de qué región proviene. No puedes escribir input: &str a secas dentro de un struct: &str es &'a str, y ese 'a tiene que ser un parámetro del propio tipo.

struct Parser<'a> {
    input: &'a str,   // el struct NO posee el texto: lo mira prestado
    pos: usize,
}

Omitir el 'a da un error inmediato, E0106 “missing lifetime specifier”, en la definición del campo. La razón es la misma contención de regiones de siempre, elevada al tipo: si el struct guarda una referencia, el compilador necesita un nombre para su región para poder garantizar, en cada uso del struct, que la instancia no sobrevive al input prestado.

Un struct puede guardar varias referencias, y entonces admite varios lifetimes —uno por cada préstamo independiente—, igual que una función. Compartir un solo 'a entre todos los campos es más simple, pero también más restrictivo: obliga a que todos los datos prestados vivan al menos la misma región.

// Dos préstamos independientes: dos lifetimes distintos.
struct Entrada<'clave, 'valor> {
    clave: &'clave str,
    valor: &'valor str,
}
// con un solo 'a ambos campos quedarían atados a la MISMA región;
// con dos, cada campo puede provenir de un dato de vida distinta

La instancia queda atada a su dato

La consecuencia práctica es contundente: un Parser<'a> es tan efímero como el &'a str que guarda. Si el texto muere, el Parser deja de ser usable en ese mismo punto. El borrow checker lo impone comparando la región de la instancia con la de su campo prestado.

fn main() {
    let parser;
    {
        let texto = String::from("clave=valor");
        parser = Parser { input: &texto, pos: 0 };   // 'a = región de `texto`
        // ... usar `parser` aquí sería válido
    } // muere `texto`: su buffer se libera
    // println!("{}", parser.input);   // ERROR E0597: `texto` does not live long enough
}

flowchart LR
texto[String texto es el dueno del buffer] -->|prestado en el campo input| parser[Instancia Parser con lifetime a]
parser --> regla[La instancia no puede vivir mas que texto]
regla --> err[Si lo intenta: E0597 does not live long enough]

Esta atadura tiene un efecto de diseño enorme: un struct con referencias no puede guardarse en estructuras de vida larga, ni devolverse desde una función que crea el dato prestado, ni almacenarse en un campo de otro objeto que le sobreviva. Es una vista temporal, y su lugar natural es la pila de llamadas cercana al dato original.

impl<'a> y métodos que devuelven referencias

Para dar métodos a un struct con lifetime, el bloque impl también declara el parámetro. La sintaxis repite 'a en tres sitios: tras impl, en el tipo, y donde haga falta en las firmas.

impl<'a> Parser<'a> {
    fn nuevo(input: &'a str) -> Self {
        Parser { input, pos: 0 }
    }

    // Devuelve una porción del input: vive tanto como el struct, es decir 'a.
    fn resto(&self) -> &'a str {
        &self.input[self.pos..]
    }
}

Fíjate en el matiz de resto: devuelve &'a str, no una referencia atada a &self. La porción sale del input original, cuya región es 'a, así que puede sobrevivir a un &self efímero. Si hubieras escrito -> &str a secas, la elisión la habría atado a self (regla del self, lección 4), que es más restrictivo. Cuando la salida proviene del dato prestado y no del struct, anota 'a explícitamente.

Los structs prestados conviven sin fricción con los parámetros de tipo: un tipo puede llevar a la vez lifetimes y genéricos, y la convención es escribir primero los lifetimes y después los tipos. Así modelas una vista prestada sobre datos de cualquier tipo.

// Lifetime y tipo genérico juntos: los lifetimes van primero.
struct Ventana<'a, T> {
    slice: &'a [T],   // una vista prestada sobre elementos de tipo T
}

impl<'a, T> Ventana<'a, T> {
    fn primero(&self) -> Option<&'a T> {
        self.slice.first()
    }
}

Prestar o poseer: la decisión de diseño

La pregunta clave al modelar un struct con datos ajenos es si debe prestar o poseer. Prestar (&'a str) evita copiar y es la base de los parsers de cero copia, los iteradores y las vistas: rapidísimo, pero ata el tipo a la vida del dato. Poseer (String) hace el tipo autónomo y libre de lifetimes, a cambio de asignar y copiar. No hay respuesta universal; hay un compromiso entre rendimiento y libertad de vida.

// Versión que POSEE: sin lifetimes, autónoma, guardable en cualquier parte.
struct ParserDueno {
    input: String,   // el struct es dueño de su texto
    pos: usize,
}

fn crear() -> ParserDueno {
    ParserDueno { input: String::from("dato local"), pos: 0 }
    // devolver esto es legal: no hay referencia que pueda colgar
}

Compara: ParserDueno puede devolverse desde crear sin problema, porque no cuelga de nada externo; el Parser<'a> prestado no podría devolverse apuntando a un String local, porque ese texto moriría al volver. La regla heurística: si el tipo va a vivir mucho, viajar lejos o guardarse en colecciones, que posea; si es una vista efímera junto al dato original y el rendimiento manda, que preste.