unsafe no apaga el borrow checker

Aquí muere la carrera de muchos programadores que llegan de C: abren un bloque unsafe esperando que Rust “se aparte” y les deje hacer lo que quieran, y descubren, atónitos, que el borrow checker sigue ahí, gritándoles igual que fuera. El malentendido es total y es caro. unsafe no desactiva el borrow checker, no relaja el sistema de tipos, no suspende las reglas de vidas ni la semántica de movimiento, y no convierte Rust en C. Es una operación puramente aditiva: suma exactamente los cinco superpoderes de la lección anterior y no resta ni una sola garantía. Dentro de unsafe, dos &mut a lo mismo siguen siendo ilegales, un String sigue sin poder sumarse a un i32, y una referencia colgante se sigue rechazando. Lo que permite aliasar libremente no es la palabra unsafe: es el puntero crudo, que vive fuera del sistema de préstamos. Confundir ambas cosas es la raíz de casi todo el unsafe mal escrito del mundo.

El borrow checker sigue plenamente activo

Demostrémoslo con código. Este fragmento no compila, y el error es exactamente el mismo que verías fuera de cualquier bloque unsafe:

fn main() {
    let mut v = vec![1, 2, 3];
    unsafe {
        let a = &mut v;
        let b = &mut v;   // ERROR: no puedes prestar `v` como mutable dos veces
        a.push(4);
        b.push(5);
    }
}

El compilador rechaza el segundo &mut v dentro del unsafe con la misma firmeza que fuera. No hubo relajación alguna. El sistema de tipos también sigue intacto: dentro de unsafe, let x: i32 = String::new(); sigue siendo un error de tipos, y una referencia que sobreviva a su dueño sigue siendo rechazada por las vidas. unsafe no tocó nada de esa maquinaria.

Esto sorprende sobre todo a quien más experiencia trae de otros lenguajes de sistemas. En C no existe una frontera análoga: el compilador nunca comprobó el aliasing, así que no hay nada que “siga activo” al entrar en una zona peligrosa. En Rust, unsafe es una anotación dentro de un lenguaje que sigue comprobándolo todo, no un regreso a un lenguaje que no comprobaba nada. La diferencia es abismal y explica por qué el unsafe de Rust es órdenes de magnitud más seguro que C entero: opera sobre un sustrato que jamás deja de vigilar el resto.

Quien aliasa es el puntero crudo, no unsafe

Entonces, ¿cómo se consigue el aliasing mutable que a veces se necesita? No abriendo un bloque unsafe, sino usando punteros crudos, que por diseño viven fuera del sistema de préstamos y por tanto no están sujetos a la regla de exclusividad:

fn main() {
    let mut x = 10;
    let p1 = &raw mut x;      // puntero crudo: crear es seguro
    let p2 = &raw mut x;      // DOS punteros mut al mismo dato: PERMITIDO
    unsafe {
        *p1 += 1;            // el bloque solo autoriza el desreferenciado
        *p2 += 1;
    }
    println!("{x}");
}

Fíjate en el reparto de papeles. Los dos &raw mut x coexisten sin queja del borrow checker porque los punteros crudos no son referencias: no participan en el análisis de préstamos. El bloque unsafe no hizo nada por permitir ese aliasing; solo autorizó el acto de desreferenciar los punteros. La libertad vino del tipo *mut T; el bloque solo abrió el quinto centímetro del camino. Esta separación es la lección entera: el peligro no está en la palabra, está en el tipo de dato que elegiste usar.

flowchart LR
subgraph Intacto[Garantias que unsafe NO toca]
  B[Borrow checker]
  T[Sistema de tipos]
  L[Vidas y movimiento]
end
subgraph Suma[Lo que unsafe anade]
  P[Cinco superpoderes]
end
Intacto --> R[Rust dentro de unsafe]
Suma --> R
style Intacto fill:#a6e3a1,color:#11111b
style Suma fill:#f38ba8,color:#11111b
style R fill:#89b4fa,color:#11111b

Aditivo, nunca sustractivo

La formulación precisa, la que conviene grabar: unsafe es un operador aditivo. Toma el lenguaje seguro completo —con todas sus comprobaciones vivas— y le añade cinco capacidades. No existe ninguna garantía que unsafe retire. Un bloque unsafe es Rust normal más cinco cosas, no Rust normal menos las comprobaciones.

Compruébalo con un caso mínimo: dentro de un bloque unsafe, el sistema de tipos sigue tan estricto como fuera.

unsafe {
    let n: i32 = "hola";   // ERROR de tipos, igual que fuera de unsafe
    let m: u8 = 300;       // ERROR: 300 no cabe en u8, el compilador lo caza
}

Ni el error de tipos ni el de rango del literal desaparecen: unsafe ni siquiera los mira, porque no forman parte de los cinco superpoderes. Cada comprobación que existía fuera sigue existiendo, palabra por palabra, dentro del bloque.

De ahí se sigue una consecuencia liberadora para escribir buen unsafe: casi todo tu código dentro del bloque sigue siendo verificado por el compilador. Si tu bloque unsafe tiene veinte líneas y solo una desreferencia un puntero crudo, el compilador aún te protege en las otras diecinueve: te caza el error de tipos, el préstamo inválido, la vida demasiado corta. Por eso la buena práctica es hacer los bloques unsafe diminutos: cuanto menos código encierres, más trabajo sigue haciendo por ti el verificador y menos superficie queda librada a tu palabra.

El precio de escapar del sistema de préstamos

Que el puntero crudo te deje aliasar no es una laguna que explotar alegremente: es una puerta con peaje. En el momento en que sales del sistema de préstamos, pierdes también su protección, y el compromiso de mantener la unicidad de cada &mut —que el borrow checker sostenía por ti— pasa a ser tuyo. Considera dos vistas mutables a mitades de un buffer, construidas a mano:

fn dos_vistas(buf: &mut [u8]) {
    let n = buf.len();
    let p = buf.as_mut_ptr();
    // SAFETY: las dos mitades no se solapan, asi que los &mut derivados son unicos.
    let (a, b) = unsafe {
        (
            std::slice::from_raw_parts_mut(p, n / 2),
            std::slice::from_raw_parts_mut(p.add(n / 2), n - n / 2),
        )
    };
    a[0] = 1;
    b[0] = 2;   // legal: a y b jamas tocan la misma celda
}

El código es correcto, pero fíjate en lo que compraste con el puntero crudo y en lo que pagas por ello: el compilador ya no verifica que a y b no se solapen; lo garantizas tú con la aritmética p y p.add(n / 2), y lo documentas en el comentario // SAFETY:. Un error de un solo carácter aquí —n / 2 trocado por n / 3— crearía dos &mut solapados y con ellos comportamiento indefinido, y el borrow checker, al que sacaste de la ecuación, no diría una palabra. Escapar del sistema de préstamos siempre es esto: un poder a cambio de una responsabilidad que antes no tenías, y que el compilador ya no vigila.

De aquí sale una consecuencia estratégica: como el borrow checker sigue vivo, escribir unsafe idiomático consiste en dejar que el compilador haga todo lo que pueda y reservar tu garantía manual para el mínimo irreducible. Los mejores bloques unsafe son aquellos en que casi todo el cuerpo se sigue verificando y solo una línea —la desreferencia, la llamada— descansa sobre tu palabra.