Closures move: forzar la captura por valor

En la lección 21.1 vimos que el compilador captura por la vía menos restrictiva: si el cuerpo solo lee, captura por referencia. Eso es óptimo… hasta que el closure necesita sobrevivir a las variables que atrapó. Un closure que presta &datos no puede vivir más que datos; en cuanto lo devuelves de una función o lo mandas a un hilo, esa referencia quedaría colgando. La palabra clave move resuelve el conflicto de raíz: obliga a capturar todo por valor, transfiriendo la posesión al closure. Deja de prestar el entorno y pasa a poseerlo. Es la llave que abre los hilos, el async y todo closure que deba viajar lejos de donde nació.

El problema: prestar lo que no sobrevive

Sin move, un closure que solo lee captura por referencia. Perfecto mientras el closure y el dato viven en el mismo ámbito; catastrófico si el closure escapa. El caso canónico es devolverlo de una función:

fn crea_sumador(base: i32) -> impl Fn(i32) -> i32 {
    |x| x + base   // ERROR: captura &base, pero base muere al retornar
}

base es un parámetro local que deja de existir cuando crea_sumador retorna. Un closure que lo prestara devolvería una referencia colgante, y el borrow checker lo prohíbe. La solución es poseer base en lugar de prestarlo:

fn crea_sumador(base: i32) -> impl Fn(i32) -> i32 {
    move |x| x + base   // base se copia dentro del closure, que ahora la posee
}

let suma10 = crea_sumador(10);
println!("{}", suma10(5)); // 15

Con move, el closure ya no depende del marco de pila de crea_sumador: se llevó su propia copia de base. Ahora puede vivir tanto como haga falta.

Qué hace move exactamente

move es un modificador que precede a las barras. Su efecto es simple y absoluto: toda variable capturada se toma por valor, ignorando la regla de “la menos restrictiva”. Lo que sin move sería &datos, con move es datos.

let datos = vec![1, 2, 3];

// Sin move: captura &datos (solo lee), datos sigue disponible.
let ver = || println!("{}", datos.len());
ver();
println!("{datos:?}");   // ok

let datos = vec![1, 2, 3];
// Con move: captura datos por valor, datos se traslada al closure.
let poseer = move || println!("{}", datos.len());
poseer();
// println!("{datos:?}");  // ERROR: datos fue movido al closure

Para tipos Copy —como i32—, “mover” es copiar, así que el original sigue usable tras el move. Para tipos no-Copy —como Vec o String—, la posesión se transfiere de verdad y el original queda inaccesible.

flowchart LR
var[Variable datos en el ambito exterior] -->|sin move| ref[Closure guarda una referencia a datos]
var -->|con move| own[Closure posee datos dentro de si]
ref --> vive[Solo valido mientras datos siga vivo]
own --> viaja[Puede viajar a un hilo o retornarse]
style ref fill:#f38ba8,color:#11111b
style own fill:#a6e3a1,color:#11111b
style viaja fill:#89b4fa,color:#11111b

Por qué los hilos lo exigen

El uso estelar de move son los hilos. thread::spawn acepta un closure con el bound F: Send + 'static: el 'static significa que el closure no puede contener referencias prestadas a nada del ámbito que lo lanzó, porque el hilo hijo podría seguir vivo cuando ese ámbito ya murió. La única forma de cumplir 'static capturando datos locales es poseerlos, y eso es exactamente lo que da move:

use std::thread;

fn main() {
    let datos = vec![1, 2, 3];

    let handle = thread::spawn(move || {
        // El hilo posee datos; no hay referencia al marco de main.
        let suma: i32 = datos.iter().sum();
        println!("suma en el hilo: {suma}");
    });

    handle.join().unwrap();
}

Sin move, el closure prestaría &datos, incumpliría 'static y el compilador lo rechazaría con un mensaje sobre tiempos de vida. move transfiere datos al hilo, que se convierte en su dueño; cuando el hilo termina, libera datos él mismo. La misma lógica gobierna el async (nivel 32): un future generado por un bloque async move debe poseer lo que usa, porque se moverá entre puntos await y quizá se ejecute en otro hilo del runtime, mucho después y muy lejos de donde se creó.

Todos estos escenarios comparten una raíz —el closure sobrevive a su ámbito de origen— y por eso todos reclaman move:

move no cambia el trait Fn

Un malentendido frecuente: creer que move hace del closure un FnOnce. No. move decide cómo se capturan las variables (por valor); los traits Fn, FnMut, FnOnce dependen de qué hace el cuerpo con ellas una vez capturadas. Son ejes independientes.

let texto = String::from("hola");
let repetible = move || texto.len();   // posee texto, pero solo lo LEE

println!("{}", repetible());   // se puede llamar
println!("{}", repetible());   // ...muchas veces: es Fn

repetible capturó texto por valor (move) pero su cuerpo solo lo lee, así que implementa Fn y se invoca cuantas veces quieras. Un move que mutara su copia sería FnMut; uno que la consumiera sería FnOnce. La palabra move gobierna la posesión; el cuerpo gobierna el trait. Confundir ambos ejes lleva a errores difíciles de leer.