El problema: mover es copiar bytes, y eso invalida los punteros internos

En el nivel 8 aprendiste que mover un valor es casi gratis: se copian las pocas palabras del stack y se invalida el origen, sin que corra ni una línea de código de usuario. Esa fue la buena noticia. Ahora viene la letra pequeña. Si mover es reubicar los bytes de un valor a otra dirección de memoria, entonces la dirección de cualquier valor puede cambiar en cualquier momento, sin previo aviso y sin que puedas intervenir. Para casi todo, da igual: los bytes son idénticos vivan donde vivan. Pero existe una familia de valores para los que no da igual —los que guardan un puntero a sí mismos—, y sobre ellos el move de Rust cae como una guillotina silenciosa. Este nivel entero nace de ese único conflicto.

Mover es reubicar, y ocurre por todas partes

Un move copia la representación superficial de un valor a otra posición de memoria y marca el origen como muerto. La palabra clave es otra posición: tras el move, el valor vive en una dirección distinta. Y esto no es un evento raro que provoques a mano; el lenguaje mueve valores constantemente, en sitios que ni miras:

let a = String::from("x");
let b = a;                       // move: reubicado por la asignacion
tragar(b);                       // move: reubicado al pasar por valor
let v = devolver();              // move: reubicado al retornar

let mut lista = vec![uno()];
lista.push(dos());               // el Vec puede realojar: reubica TODO su contenido
std::mem::swap(&mut x, &mut y);  // reubica intercambiando dos valores
let z = std::mem::replace(&mut r, otro()); // reubica sacando el viejo

Asignar, pasar a una función, retornar, insertar en un contenedor que crece y realoja, swap, replace, take: cada uno de estos reubica valores. La conclusión incómoda es que un valor de Rust no tiene una dirección estable garantizada. Puede estar hoy en 0x1000 y, tras un inocente push a un vector que lo contenía, mañana en 0x2000. El compilador se reserva ese derecho porque de él dependen el rendimiento y la ergonomía de todo el lenguaje.

Todo valor cae en uno de dos mundos, y la diferencia entre ellos es el eje del nivel entero:

El valor que se apunta a sí mismo

Para casi todos los valores, la reubicación es inocua: los bytes de un String o de un i32 significan lo mismo en cualquier dirección. El problema aparece cuando entre esos bytes hay una dirección de memoria que apunta al propio valor. Imagina un struct que guarda un buffer y, junto a él, un puntero a ese buffer:

struct Autoref {
    dato: [u8; 4],
    puntero: *const u8,   // se pretende que apunte a self.dato
}

Supón que este Autoref vive en la dirección 0x1000, de modo que dato empieza en 0x1000 y puntero vale exactamente 0x1000: apunta a su propio campo vecino. Ahora lo mueves —una asignación, un retorno, lo que sea— y el valor aterriza en 0x2000. El memcpy copia los ocho-y-pico bytes literalmente: dato se recrea en 0x2000, pero puntero se copia tal cual, y sigue valiendo 0x1000.

// Antes del move:  el struct vive en 0x1000
//   dato    -> ocupa 0x1000..0x1004
//   puntero -> vale 0x1000   (correcto: apunta a dato)
//
// Despues del move: el struct vive en 0x2000
//   dato    -> ahora ocupa 0x2000..0x2004
//   puntero -> SIGUE valiendo 0x1000   (colgante: alli ya no hay nada suyo)

El puntero quedó colgante. Apunta a una dirección que ya no contiene el campo dato —quizá basura, quizá otro valor reciclado por el stack—. Leer a través de él es undefined behavior. Y fíjate en lo pérfido del caso: el move no rompió nada visible, no falló ninguna aserción, los bits del puntero se preservaron con toda fidelidad. Precisamente por preservarlos con fidelidad, el puntero ahora miente.

Que la dirección cambia con el move no es una metáfora; se puede observar. La función direccion extrae la posición actual de un valor, y basta un move para verla saltar:

fn direccion<T>(v: &T) -> usize {
    v as *const T as usize        // la direccion donde vive el valor ahora mismo
}

fn main() {
    let s = String::from("dato");
    println!("antes del move: {:#x}", direccion(&s));
    let movido = s;               // move: el valor se reubica en `movido`
    println!("tras el move:   {:#x}", direccion(&movido)); // otra direccion distinta
}

Para un String este salto es inofensivo, porque ninguno de sus bytes guardaba la dirección vieja. El problema aparece solo cuando sí la guardaba: entonces el salto de dirección deja atrás un puntero que apuntaba al sitio de antes.

Por qué Rust no puede repararlo por ti

En C++ este problema se resuelve —a un coste— con un constructor de movimiento: código de usuario que corre durante el move y que puede reapuntar el puntero a la nueva dirección. El objeto se entera de que lo están reubicando y arregla sus punteros internos sobre la marcha. Rust renunció a eso deliberadamente: como viste, en un move de Rust no corre ningún código de usuario. No hay ningún gancho donde meter la reparación. La misma decisión que hace los moves gratis y predecibles es la que deja los punteros internos sin nadie que los actualice.

// C++ (conceptual): el move ejecuta un cuerpo que puede reapuntar el campo
//   Autoref(Autoref&& otro) { dato = otro.dato; puntero = &dato; }  // se arregla
//
// Rust: el move es un memcpy y punto; no hay cuerpo donde arreglar nada
//   let movido = autoref;   // `puntero` se copia tal cual; nadie lo reapunta

La asimetría es total. C++ paga con un constructor que puede tener bugs y con un coste oculto en cada move, pero a cambio puede sostener valores auto-referenciales. Rust cobra moves triviales y sin sorpresas, pero al precio de que un valor auto-referencial, movido, queda roto sin remedio automático.

Rust queda entonces ante una disyuntiva. O bien prohíbe de raíz construir valores auto-referenciales —y en efecto, en Rust seguro casi no se pueden expresar, como verás en la siguiente lección—, o bien inventa una forma de prometerle al compilador que cierto valor no se moverá nunca, de modo que sus punteros internos permanezcan válidos. Esa segunda vía es Pin, y es la protagonista del nivel. Pero antes de conocer la solución hay que sentir el peso del problema: no es un caso académico, porque —lo verás pronto— cada función async no trivial fabrica uno de estos valores.

flowchart LR
A[Struct en 0x1000 con puntero que vale 0x1000] -->|move copia los bytes tal cual| B[Struct en 0x2000]
B --> C[El campo dato viaja a 0x2000]
B --> D[El puntero sigue valiendo 0x1000]
D --> E[Apunta a memoria que ya no es el dato y queda colgante]
style A fill:#89b4fa,color:#11111b
style B fill:#cba6f7,color:#11111b
style D fill:#f9e2af,color:#11111b
style E fill:#f38ba8,color:#11111b