Auto-traits y unsafe impl: la responsabilidad del marcador

Hemos dicho muchas veces que el compilador “deduce” Send y Sync. Esta lección explica el mecanismo exacto de esa deducción —una recursión estructural sobre los campos de cada tipo— y llega al lugar donde la automatización se detiene: los tipos construidos sobre punteros crudos, donde el compilador es deliberadamente conservador y calla. Ahí, y solo ahí, aparece unsafe impl Send o unsafe impl Sync: una promesa manual que devuelve al programador la carga de la prueba que el sistema suele llevar por él.

La derivación estructural

Un auto-trait no se deriva con #[derive]: el compilador lo concede recorriendo la estructura del tipo. La regla es una recursión de una sola línea: un tipo compuesto es Send si todos sus campos son Send, y Sync si todos sus campos son Sync. El caso base son los tipos primitivos —enteros, bool, char— que son ambos; el paso inductivo son los struct, enum y tuplas, que heredan la conjunción de sus partes.

use std::rc::Rc;

struct Limpio {
    id: u64,
    nombre: String,
} // Send + Sync: todos sus campos lo son

struct Contaminado {
    id: u64,
    cache: Rc<String>, // Rc no es Send ni Sync...
} // ...asi que Contaminado tampoco lo es, automaticamente

No hay que anotar nada. Añadir un Rc en lo más hondo de una jerarquía de struct retira Send y Sync de todo lo que lo contiene, en cascada, hasta la raíz. Esta propagación silenciosa es la que hace el sistema infalible: es imposible olvidarse de marcar un tipo como inseguro, porque nadie lo marca a mano.

Si intentas enviar un Contaminado a otro hilo, el compilador reconstruye la cadena hasta el campo culpable:

error[E0277]: `Rc<String>` cannot be sent between threads safely
  = note: required because it appears within the type `Contaminado`
  = note: required by a bound in `spawn`

El diagnóstico es la demostración leída al revés: Contaminado no es Send porque contiene un Rc<String> que no lo es. No hay que interpretar nada; el compilador cita el campo exacto que rompe la propiedad y la regla que la exige.

Retirar el marcador con PhantomData

A veces la derivación automática concede un marcador que tú no quieres. Un tipo que envuelve un puntero pero que, conceptualmente, representa algo atado a un hilo concreto no debería ser Send aunque sus campos visibles lo permitan. La herramienta idiomática para retirarlo sin coste es PhantomData, un campo de tamaño cero que existe solo para que el compilador lo tenga en cuenta al deducir los auto-traits.

use std::marker::PhantomData;
use std::rc::Rc;

struct SoloEsteHilo {
    dato: u64,
    _marca: PhantomData<Rc<()>>, // hereda el !Send + !Sync de Rc
}

PhantomData<T> copia los Send y Sync de T sin almacenar ningún T. Al incrustar PhantomData<Rc<()>>, el struct hereda la ausencia de ambos marcadores de Rc, y queda !Send y !Sync —sin ocupar ni un byte y sin una sola instrucción en ejecución—. Es la vía estable para decir “trátame como si contuviera algo atado a un hilo”.

La marca no cuesta ni un byte, y puedes comprobarlo:

use std::mem::size_of;

// size_of::<SoloEsteHilo>() == size_of::<u64>() == 8
// PhantomData<Rc<()>> ocupa 0 bytes: solo altera los auto-traits.

El campo fantasma cambia el sistema de tipos sin tocar la representación en memoria: es una anotación dirigida al compilador, no un dato que se almacene.

Cuándo el compilador es demasiado conservador

La derivación estructural es segura pero conservadora: ante un puntero crudo, el compilador siempre dice !Send y !Sync, porque un *mut T no ofrece ninguna garantía y él no puede adivinar tus invariantes. La inmensa mayoría de las veces esa prudencia es correcta. Pero al escribir estructuras de datos de bajo nivel —un canal entre hilos, una cola sin bloqueo, un Arc propio, un envoltorio de un recurso de C— tú sabes algo que el compilador no puede ver: que tu tipo, pese a contener punteros crudos, sincroniza sus accesos correctamente y es seguro de enviar o compartir.

use std::ptr::NonNull;

// Un contenedor que posee en exclusiva su asignacion en el heap.
struct MiCaja<T> {
    ptr: NonNull<T>, // contiene un puntero crudo: el compilador lo hace !Send
}

MiCaja<T> es, en su semántica, tan dueño de su dato como un Box<T>, y por tanto debería ser Send cuando T lo sea. Pero el NonNull lo ha vuelto !Send por precaución. El compilador no se equivoca por capricho: se equivoca hacia el lado seguro, y te cede a ti la última palabra.

unsafe impl: firmar la garantía con tu nombre

Esa última palabra es unsafe impl. Afirmas manualmente el marcador, y el unsafe proclama que la obligación de prueba —la que el compilador descarga por ti en los tipos normales— pasa ahora a tus manos.

// Prometo que MiCaja posee su dato en exclusiva, como Box:
// enviarla a otro hilo es tan seguro como enviar el T que contiene.
unsafe impl<T: Send> Send for MiCaja<T> {}
unsafe impl<T: Sync> Sync for MiCaja<T> {}

Cada línea es un teorema que tú te comprometes a haber demostrado. unsafe impl Send afirma: “mover esto a otro hilo no puede causar una carrera”. unsafe impl Sync afirma: “que dos hilos compartan &esto es seguro”. Los límites T: Send y T: Sync no son adorno: replican la derivación estructural que harías a mano, propagando la exigencia al contenido. Si mientes —si tu tipo comparte estado mutable sin sincronizar y aun así lo declaras Sync— el compilador te creerá, y habrás reabierto exactamente la puerta a las condiciones de carrera que todo este nivel existe para cerrar. Nadie te avisará: el unsafe era el aviso.

flowchart TD
T[Defines un tipo] --> aut[Contiene solo campos normales]
aut -->|si| derive[El compilador deduce Send y Sync de los campos]
aut -->|no, hay punteros crudos| cons[El compilador lo marca no Send por precaucion]
cons --> dec[Sabes que es seguro y puedes probarlo]
dec -->|no| stop[Deja el no Send, es correcto]
dec -->|si| ui[unsafe impl Send, asumes la carga de la prueba]
style derive fill:#a6e3a1,color:#11111b
style stop fill:#fab387,color:#11111b
style ui fill:#f38ba8,color:#11111b