Structs auto-referenciales: imposibles de nombrar, y por qué async los fabrica

La lección anterior mostró qué le pasa a un valor auto-referencial cuando lo mueves: se rompe. La pregunta natural es entonces por qué el compilador te deja construir semejante bomba. La respuesta, sorprendente, es que en Rust seguro no te deja: intentar escribir un struct que guarde una referencia a otro de sus campos choca contra un muro de lifetimes que no hay forma de sortear. No es una prohibición explícita con un mensaje del tipo auto-referencia no permitida; es algo más profundo: la auto-referencia es innombrable en el sistema de lifetimes. Y aquí está el giro que justifica todo el nivel: esa forma que el lenguaje no te deja escribir a mano es exactamente la que el compilador genera, por ti y a tus espaldas, cada vez que compilas una función async que sostiene una referencia a través de un await.

El struct que no se puede escribir

Intentémoslo directamente. Un struct que posee un String y guarda, junto a él, una &str que apunta a una porción de ese mismo String:

struct Autoref {
    dato: String,
    vista: &str,   // pretende apuntar a una parte de self.dato
}

No compila, y el primer error es que vista necesita un lifetime: &str es siempre &'a str para algún 'a. Así que te preguntas cuál. ¿El lifetime del Autoref? Pero el Autoref contiene al String; su duración es la del propio struct que estás definiendo. Necesitarías escribir algo como me presto a mí mismo mientras yo exista, y ese lifetime no tiene nombre en Rust. Cualquier 'a que intentes poner será un parámetro externo, ligado a algo de fuera del struct, nunca al dato de dentro.

struct Autoref<'a> {
    dato: String,
    vista: &'a str,   // 'a viene de fuera; no puede ser el propio dato
}
// Y aunque lo declares, construirlo es imposible en seguro:
// necesitarias prestar `dato` a `vista` DENTRO del mismo constructor,
// creando un prestamo que dura tanto como el valor que lo contiene.

El borrow checker rechaza construirlo porque tendrías que tomar prestado dato para inicializar vista en el mismo instante en que el valor todavía se está formando, y ese préstamo tendría que vivir tanto como el struct entero —un préstamo de un valor por parte de sí mismo—. Las reglas de préstamo no admiten esa figura. No es que Rust prohíba la auto-referencia: es que carece de vocabulario para expresarla de forma segura. La seguridad de los lifetimes se compra al precio de que ciertas estructuras válidas se vuelvan inefables.

El intento de construirlo lo deja crudo: el momento en que dato entra en el struct es un move, y ese move invalidaría la vista que acabas de crear.

fn construir() -> Autoref {          // ¿que lifetime tendria el campo vista?
    let dato = String::from("hola mundo");
    let vista = &dato[0..4];         // vista presta de dato, que vive en el stack local...
    Autoref { dato, vista }          // ...pero `dato` SE MUEVE al struct: vista quedaria colgante
}                                    // ERROR: no se puede devolver un prestamo de un local

async fn es una máquina de estados

Aquí converge todo. Una función async no se ejecuta cuando la llamas: devuelve un Future, un valor que representa el cálculo suspendible. Y ese Future lo fabrica el compilador transformando el cuerpo de tu función en una máquina de estados: un enum implícito con una variante por cada tramo entre puntos await, que guarda en sus campos todas las variables locales que deben sobrevivir a una suspensión.

async fn saludar() -> usize {
    let dato = String::from("hola mundo");   // local
    let vista = &dato[0..4];                 // referencia a otro local
    esperar_un_tick().await;                 // SUSPENSION: se guarda el estado
    println!("{vista}");                     // vista se usa DESPUES del await
    vista.len()
}

Piensa qué debe recordar la máquina de estados al suspenderse en el await. Cuando saludar se aparque ahí y devuelva el control al ejecutor, tiene que conservar dato —porque println! lo usará después a través de vista— y tiene que conservar vista —porque también se usa después—. Pero vista es &dato[0..4]: una referencia a otro campo de la misma máquina de estados. El Future generado tiene, conceptualmente, esta forma:

// Aproximacion de lo que el compilador genera:
struct FuturoSaludar {
    dato: String,          // el buffer, dueño
    vista: *const u8,      // apunta DENTRO de self.dato: auto-referencia
    // ...estado de en que punto del await estamos
}

Ahí está, otra vez, el Autoref de la primera lección —el struct innombrable— salvo que esta vez no lo escribiste tú: lo generó el compilador. Y no fue un caso rebuscado: bastó con hacer lo más natural del mundo en código async, sostener una referencia a un dato local a través de un await. La forma que el lenguaje te prohíbe escribir a mano es la que produce a destajo en cuanto usas async de verdad.

Con más precisión, la máquina de estados es un enum con una variante por cada tramo entre puntos await, y cada variante guarda solo los locales que deben sobrevivir a esa suspensión:

// Aproximacion de lo que el compilador genera para `saludar`:
enum FuturoSaludar {
    Inicio,                     // aun no se ha ejecutado nada
    TrasEsperar {               // suspendido en el punto await
        dato: String,           // el buffer, dueño
        vista: *const u8,       // apunta DENTRO de self.dato: auto-referencia
    },
    Terminado,                  // ya produjo su Output
}

Por qué esto obliga a introducir Pin

La consecuencia encadena con la lección anterior de forma inevitable. Ese FuturoSaludar contiene un puntero a uno de sus propios campos; por tanto, si lo mueves después de haber empezado a ejecutarlo, el puntero vista quedará colgante, apuntando a donde dato estaba antes del move. Pero un Future está hecho para ser sondeado (poll) muchas veces por un ejecutor, con suspensiones en medio. Si entre dos sondeos el ejecutor pudiera mover el futuro —guardarlo en un Vec que realoja, pasarlo por valor, intercambiarlo—, lo corrompería.

De modo que el Future auto-referencial impone una regla dura: una vez que empieza a ejecutarse, no debe moverse jamás. Necesitamos una manera de expresar esa regla en el sistema de tipos, que el ejecutor esté obligado a respetar y que el compilador verifique. Esa manera es Pin, y por eso Future::poll no recibe un &mut self corriente sino un Pin<&mut Self>. La lección tres construye ese contrato desde cero.

flowchart TB
A[async fn saludar] -->|el compilador transforma| B[Maquina de estados FuturoSaludar]
B --> C[Campo dato el String propietario]
B --> D[Campo vista puntero dentro de dato]
D -->|apunta a| C
C --> E[Es auto-referencial]
D --> E
E --> F[Moverlo tras empezar deja vista colgante]
F --> G[Regla no moverse una vez sondeado]
style B fill:#cba6f7,color:#11111b
style E fill:#f9e2af,color:#11111b
style F fill:#f38ba8,color:#11111b
style G fill:#a6e3a1,color:#11111b