`Unpin`: el permiso para moverse, y por qué casi todo lo tiene

Si Pin fuera una restricción que cae sobre todos los valores, sería insoportable: no podrías mover un String, ni reasignar un i32, sin pelear con envoltorios. Pero tu experiencia diaria con Rust dice lo contrario: el noventa y nueve por ciento del código nunca se topa con Pin. La pieza que reconcilia ambas cosas es Unpin, un auto-trait con el nombre más contraintuitivo de la biblioteca estándar. Unpin no significa este tipo no se puede pinchar. Significa lo opuesto: a este tipo el pinchado no le afecta; muévelo cuando quieras, aunque esté dentro de un Pin. Y como casi todos los tipos lo cumplen automáticamente, Pin se vuelve transparente para casi todo, y solo muerde donde de verdad hace falta: los poquísimos valores que guardan un puntero a sí mismos.

Un auto-trait que reparte permisos

Unpin es un auto-trait, de la misma familia que Send y Sync: el compilador lo implementa solo, automáticamente, para todo tipo cuyas partes sean todas Unpin. No lo escribes; lo deduce la estructura. Y como los bloques básicos —i32, bool, char, String, Vec<T>, Box<T>, &T— son todos Unpin, cualquier struct o enum que compongas con ellos hereda Unpin gratis. En la práctica, casi todos los tipos de Rust son Unpin.

// Unpin se deriva por composicion, igual que Send y Sync: si todos los campos
// son Unpin, el tipo entero es Unpin, sin que escribas absolutamente nada.
struct Punto { x: i32, y: String }   // i32 y String son Unpin => Punto es Unpin

La semántica es la clave, y hay que decirla con cuidado. T: Unpin significa: pinchar un T no aporta ninguna garantía útil, porque mover un T nunca lo corrompe. Es la afirmación de que T no tiene punteros internos que un move fuera a invalidar. Un String puede moverse un millón de veces sin daño; sus tres palabras del stack significan lo mismo en cualquier dirección. Por eso String es Unpin: la promesa de inmovilidad que ofrece Pin no le sirve de nada, porque no la necesita.

Pin sobre un Unpin no restringe nada

Aquí se cierra el círculo con la lección anterior. Dijimos que Pin<&mut T> se niega a entregar un &mut T. Matiz: se niega salvo que T sea Unpin. Cuando el tipo es Unpin, esa negación desaparece, porque mover el valor no hace daño y no hay nada que proteger:

use std::pin::Pin;

let mut n = 42_i32;                     // i32 es Unpin
let mut p: Pin<&mut i32> = Pin::new(&mut n); // Pin::new: seguro, sin unsafe, porque es Unpin

let r: &mut i32 = p.as_mut().get_mut(); // get_mut: seguro, porque i32 es Unpin
*r += 1;                                // puedes mutarlo y moverlo a placer

Dos consecuencias visibles. Primera: Pin::new es un constructor seguro para tipos Unpin —no necesitas unsafe ni prometer nada, porque no hay invariante que romper—. Segunda: Pin::get_mut te devuelve un &mut T seguro si T: Unpin. Es decir, sobre un tipo Unpin, Pin es un envoltorio transparente que no te quita ninguna capacidad. Por eso puedes escribir toneladas de código sin enterarte de que Pin existe: todo lo que tocas es Unpin, y Pin sobre Unpin es un no-operar.

El requisito no es una convención: está en la propia firma de la biblioteca estándar, como una acotación Unpin que restringe cuándo esos métodos seguros existen.

// Esquema de las firmas reales (simplificado):
impl<P> Pin<P> where P: Deref, P::Target: Unpin {
    pub fn new(pointer: P) -> Pin<P> { /* seguro: el destino es Unpin */ }
}
impl<'a, T: ?Sized> Pin<&'a mut T> {
    pub fn get_mut(self) -> &'a mut T where T: Unpin { /* seguro: mover no daña */ }
}

Quién es !Unpin, y cómo optar por serlo

Solo un puñado de tipos no son Unpin, y son exactamente los que guardan punteros a sí mismos. El caso estrella: los Future que el compilador genera a partir de un async fn cuando alguna referencia cruza un await (lección 2). El compilador los marca !Unpin porque sí se corromperían al moverse. Para esos, Pin recupera todos sus dientes: Pin::new deja de estar disponible (hay que usar unsafe o los ayudantes de la lección 5), y get_mut seguro desaparece.

También puedes volver !Unpin un tipo propio, aunque rara vez lo harás a mano. El marcador es PhantomPinned, un campo de tamaño cero que le dice al compilador no me des Unpin automático:

use std::marker::PhantomPinned;

struct Inmovible {
    dato: String,
    interno: *const u8,     // pretende apuntar dentro de self.dato
    _fija: PhantomPinned,   // este campo hace que Inmovible sea !Unpin
}

Sin PhantomPinned, ese struct sería Unpin por composición —pese a tener un puntero crudo— y Pin no lo protegería, porque el compilador no sabe que el puntero es interno. PhantomPinned es la forma de decir este tipo tiene una razón real para no moverse; hazme cumplir la garantía de Pin.

El contraste se ve al intentar las mismas operaciones sobre un tipo de cada mundo:

use std::pin::Pin;
use std::marker::PhantomPinned;

// Mundo Unpin: todo permitido, sin unsafe
let mut n = 10_i32;
let p = Pin::new(&mut n);         // compila: i32 es Unpin
let r: &mut i32 = p.get_mut();    // compila: recuperas el &mut gratis
*r += 1;

// Mundo !Unpin: las mismas llamadas dejan de estar disponibles
struct Nudo { _fija: PhantomPinned }
let mut nudo = Nudo { _fija: PhantomPinned };
// let p = Pin::new(&mut nudo);   // ERROR: Nudo no es Unpin, Pin::new no aplica
// let r = p.get_mut();           // ERROR: get_mut seguro exige Unpin
// Para pinchar un Nudo hay que usar Box::pin, pin!, o new_unchecked (unsafe).

La misma línea que compila para el i32 se apaga para el Nudo. No hay dos APIs distintas: es una API cuyos métodos seguros exigen Unpin, de modo que el compilador te deja pasar cuando mover es inocuo y te frena cuando no. Unpin es, literalmente, el interruptor que decide si Pin estorba o desaparece.

flowchart TD
A[Un tipo cualquiera] --> B{Guarda un puntero a si mismo}
B -->|no, el caso comun| C[Es Unpin de forma automatica]
B -->|si, futuros o PhantomPinned| D[Es no Unpin]
C --> E[Pin es transparente con get mut y new seguros]
D --> F[Pin ata de verdad sin get mut seguro ni Pin new]
E --> G[El codigo normal nunca nota Pin]
F --> H[Solo estos pocos tipos pagan la restriccion]
style C fill:#a6e3a1,color:#11111b
style D fill:#f38ba8,color:#11111b
style G fill:#89b4fa,color:#11111b
style H fill:#f9e2af,color:#11111b