'static y los patrones de lifetimes del día a día

'static es el lifetime más largo posible: la región que abarca todo el programa. Pero es también el más malentendido de Rust, porque significa dos cosas distintas según dónde aparezca: como referencia, &'static T promete un dato válido hasta el final del proceso; como cota, T: 'static promete un tipo que no contiene referencias efímeras. Esta lección cierra el nivel destilando 'static y catalogando los patrones y errores de lifetimes que de verdad te encontrarás escribiendo Rust.

Los dos significados de 'static

Aquí está la confusión que hay que disolver de una vez. 'static aparece en dos posiciones gramaticalmente distintas, y significan cosas diferentes.

La trampa: String cumple String: 'static aunque no viva “para siempre” —un String local se libera al salir de scope—. La cota T: 'static no dice “vive eternamente”; dice “podría vivir hasta el final del programa porque no depende de ningún préstamo más corto”. Un tipo que posee todos sus datos siempre satisface 'static; solo lo incumple un tipo que guarda una referencia efímera, como Parser<'a> con 'a distinto de 'static.

fn exige_static<T: 'static>(_valor: T) {}

fn main() {
    let s = String::from("dueño de sus bytes");
    exige_static(s);          // OK: `String: 'static`, aunque `s` sea local y efímero
    exige_static(42_i32);     // OK: un i32 no contiene referencias

    let texto = String::from("...");
    let vista: &str = &texto;
    // exige_static(vista);   // ERROR: `&str` con lifetime local NO es 'static
}

La cota T: 'static es una de las más frecuentes de las bibliotecas: la piden thread::spawn, Box<dyn Any>, muchos canales y casi todo lo que guarda un valor por tiempo indefinido. El sentido es siempre el mismo: “no me des algo que dependa de un préstamo que pueda caducar antes que yo”. Un valor que posee sus datos la cumple sin esfuerzo; uno que guarda una referencia efímera, nunca. Por eso, cuando una API te exige 'static, la respuesta idiomática casi nunca es forzar el lifetime, sino entregar la propiedad —clonar a un String, envolver en un Arc— para que el valor deje de depender de nada externo.

De dónde salen las &'static

Referencias genuinamente &'static hay tres fuentes principales. La más común, y la que ya usabas sin saberlo: los literales de cadena. Todo "texto" incrustado en el código vive en el binario y es un &'static str.

let saludo: &'static str = "hola";   // el literal vive en el binario: 'static

static VERSION: &str = "1.0";        // un `static` también dura todo el programa
const MAX: u32 = 100;                // las const se materializan donde se usan

La segunda fuente son los static: un ítem static ocupa una dirección fija durante toda la ejecución, así que las referencias a él son &'static. La tercera, más avanzada, es filtrar memoria a propósito con Box::leak, que renuncia a liberar un Box y te devuelve un &'static mut T válido para siempre —útil en arranque de programas, peligroso como costumbre—.

fn config_global() -> &'static str {
    let cargada = String::from("valor leído al arrancar");
    Box::leak(cargada.into_boxed_str())   // renuncia a liberar: la vista vive todo el programa
}

Box::leak convierte propiedad en una &'static: cedes la liberación a cambio de una referencia válida hasta el final del proceso. Es legítimo para inicializar un recurso global una vez, pero veneno como costumbre, porque cada fuga es memoria que ya no vuelve.

Los errores que aparecerán de verdad

Tres patrones concentran la mayoría de las peleas con lifetimes en el día a día. Conócelos y la mayoría de tus errores se resolverán en segundos.

Devolver una referencia a un local (E0515). El más frecuente. La cura nunca es forzar 'static, sino devolver la propiedad.

fn mal() -> &'static str {
    let local = String::from("efímero");
    // &local   // ERROR E0515: cannot return reference to local variable
    "literal"   // esto sí: un literal es de verdad 'static
}

fn bien() -> String {
    String::from("devuelvo el dueño, no una referencia")   // sin lifetimes, sin drama
}

Hilos y 'static (el spawn). thread::spawn exige que el closure sea 'static: como el hilo puede vivir más que quien lo lanzó, no puede capturar referencias efímeras. La solución idiomática es move para poseer lo capturado, o Arc<T> para compartir propiedad.

use std::thread;
use std::sync::Arc;

fn main() {
    let datos = Arc::new(vec![1, 2, 3]);
    let copia = Arc::clone(&datos);
    thread::spawn(move || {                 // `move`: el closure posee `copia`
        println!("{:?}", copia);            // Arc<Vec<_>>: 'static, sin préstamos cortos
    });
}

Objetos de trait y su lifetime por defecto. Un Box<dyn Trait> es en realidad Box<dyn Trait + 'static> por defecto. Si el objeto guarda referencias efímeras, debes anotarlo: Box<dyn Trait + 'a>.

trait Dibuja { fn render(&self) -> String; }

// Por defecto el objeto de trait es 'static: no captura préstamos cortos.
fn en_caja(x: Box<dyn Dibuja>) -> Box<dyn Dibuja> { x }   // = Box<dyn Dibuja + 'static>

// Si el objeto sí guarda referencias efímeras, declara su región con '_ o 'a:
fn prestado<'a>(x: Box<dyn Dibuja + 'a>) -> Box<dyn Dibuja + 'a> { x }

flowchart TB
err[Error de lifetime] --> tipo[Que forma tiene?]
tipo -->|devuelvo referencia a un local| own[Devuelve el dueno por valor]
tipo -->|closure a otro hilo| mv[Usa move o Arc para poseer]
tipo -->|struct guarda una vista| dec[Decide: prestar con lifetime o poseer]
own --> fin[Resuelto sin sobre-restringir]
mv --> fin
dec --> fin

No sobre-restrinjas: 'static no es un martillo

El antipatrón más dañino del principiante es sembrar 'static para acallar al compilador. Casi siempre es un diagnóstico equivocado: 'static es una restricción fortísima —exige que el dato viva todo el programa o que el tipo no tenga préstamos cortos— y usarla como parche convierte una firma flexible en una rígida que rechaza usos legítimos.