Los cinco superpoderes que solo unsafe desbloquea

La imaginación popular pinta unsafe como una compuerta a un abismo sin fondo: dentro, todo vale. La realidad es mucho más modesta y por eso mucho más tranquilizadora. unsafe desbloquea una lista cerrada y numerable de exactamente cinco capacidades adicionales, definidas con precisión en la referencia del lenguaje. Desreferenciar un puntero crudo, llamar a una función unsafe, leer o escribir un static mut, implementar un trait unsafe, y acceder a los campos de una union. Eso es todo. Ni una operación más se desbloquea. Todo lo demás dentro de un bloque unsafe es Rust idéntico al de fuera, con sus mismas reglas. Aprender esta lista de memoria no es pedantería académica: es la forma más rápida de desactivar el miedo, porque convierte una nube difusa de “aquí pasan cosas peligrosas” en cinco puntos concretos que un revisor puede buscar, contar y auditar.

Superpoderes uno y dos: punteros crudos y funciones unsafe

Desreferenciar un puntero crudo (*const T o *mut T) es el primero. Nota la asimetría clave: crear un puntero crudo y hacer aritmética con él es seguro; lo único que exige unsafe es desreferenciarlo, porque solo ahí puede ocurrir el desastre.

let x = 42;
let p: *const i32 = &x;          // crear el puntero: seguro
let q = p.wrapping_add(1);       // aritmetica: seguro
let valor = unsafe { *p };       // desreferenciar: superpoder

Llamar a una función unsafe es el segundo, e incluye las funciones extern de otro lenguaje (FFI). En la edición 2024 el propio bloque extern debe marcarse unsafe extern, subrayando que enlazar con símbolos externos es en sí una promesa:

unsafe extern "C" {
    fn abs(entrada: i32) -> i32;
}

let a = unsafe { abs(-5) };      // llamar a la funcion externa

Superpoderes tres, cuatro y cinco: static mut, traits unsafe y union

Acceder o modificar un static mut es el tercero. Una variable global mutable es una fuente perpetua de carreras de datos, así que cada acceso exige unsafe. En la edición 2024, además, crear referencias a un static mut es un error: debes usar los operadores de préstamo crudo &raw const y &raw mut.

static mut CONTADOR: u32 = 0;

unsafe {
    let p = &raw mut CONTADOR;   // no `&mut CONTADOR`: en 2024 es error
    *p += 1;
}

Implementar un trait unsafe es el cuarto. Traits como Send y Sync son unsafe porque implementarlos es afirmar una propiedad que el compilador no puede verificar —que tu tipo es seguro de mover entre hilos, o de compartir por referencia—. La palabra unsafe en el impl es tu firma sobre esa afirmación.

struct MiPuntero(*mut u8);

// Afirmo que mover MiPuntero entre hilos es seguro. El compilador no lo sabe.
unsafe impl Send for MiPuntero {}

De los cinco, este es el que más gente ejerce sin verlo como tal: cada vez que envuelves un puntero en un tipo y quieres compartirlo entre hilos, tarde o temprano escribes una unsafe impl Send o unsafe impl Sync. Y es también el más traicionero, porque su contrato no es local —no basta mirar una línea— sino global: afirmas algo sobre todos los usos concurrentes posibles del tipo. Mentir aquí no produce un fallo en la línea del impl, sino una carrera de datos que aflora a kilómetros, en otro hilo, bajo carga.

Acceder a los campos de una union es el quinto. Una union guarda varios campos en el mismo espacio de memoria; leer un campo distinto del que se escribió reinterpreta los bits, y esa reinterpretación puede ser inválida. Por eso leer un campo es un superpoder (escribir uno de tipo Copy, no).

union Bits {
    entero: u32,
    flotante: f32,
}

let b = Bits { entero: 0x3f80_0000 };
let f = unsafe { b.flotante };   // reinterpreta los mismos bits como f32

Cinco y solo cinco. La referencia del lenguaje las enumera de forma exhaustiva, y esa exhaustividad es en sí una promesa: si una operación no figura en esta lista, entonces no necesita unsafe, porque el lenguaje ya demostró que no puede, por sí sola, provocar comportamiento indefinido. Sumar enteros, indexar un Vec, mover un valor, clonar, iterar: nada de eso aparece, porque nada de eso puede corromper la memoria sin pasar antes por una de las cinco puertas.

flowchart TD
U[La palabra unsafe] --> P1[Desreferenciar puntero crudo]
U --> P2[Llamar funcion unsafe o extern]
U --> P3[Acceder a static mut]
U --> P4[Implementar trait unsafe]
U --> P5[Leer campo de union]
U -.no desbloquea nada mas.-> X[El resto es Rust normal]
style U fill:#f38ba8,color:#11111b
style X fill:#a6e3a1,color:#11111b

Lo que queda fuera de la lista

Tan instructivo como saber qué desbloquea unsafe es ver qué no desbloquea, porque revela cuánto sigue siendo Rust normal. Ninguna de estas operaciones —todas potencialmente peligrosas en C— necesita unsafe en Rust, porque el lenguaje ya garantiza su seguridad:

let mut v = vec![1, 2, 3];
let x = v[1];                   // indexar: comprobado en ejecucion, sin unsafe
v.push(4);                      // realojar: Vec mantiene sus invariantes por ti
let suma: i32 = v.iter().sum(); // iterar y sumar: sin unsafe
let w = v.clone();              // clonar: sin unsafe

Indexar fuera de rango provoca un panic, no un acceso salvaje; realojar el Vec es correcto por construcción; iterar respeta las vidas. Que nada de esto figure entre los cinco superpoderes es la otra cara de la promesa: el peligro está acotado a una lista cerrada, y todo lo que queda fuera de ella el compilador lo sostiene por ti.