El patrón central: un núcleo unsafe tras una API 100% segura

Casi todo std está construido sobre unsafe. Vec, String, Rc, Mutex, HashMap: por dentro, todos manipulan punteros crudos, memoria sin inicializar y llamadas que el compilador no puede verificar. Y sin embargo tú los usas miles de veces sin escribir una sola línea de unsafe. Eso no es casualidad: es el patrón central de la programación de sistemas en Rust. Un núcleo unsafe, diminuto y auditado, se encierra tras una API completamente segura cuyas invariantes garantiza el autor. El compilador verifica al usuario; el autor verifica el núcleo; entre ambos, una frontera de confianza. Dominar Rust de sistemas es dominar esa frontera.

Qué es y qué no es unsafe

Primero, demoler el malentendido. unsafe no apaga el borrow checker, no desactiva el sistema de tipos, no vuelve tu código “peligroso” por decreto. Lo único que hace es concederte cinco superpoderes que el resto del lenguaje te niega porque no puede verificar su corrección:

• Desreferenciar un puntero crudo (*const T, *mut T).
• Llamar a una función o método unsafe.
• Acceder o mutar una static mut.
• Implementar un trait unsafe, como Send o Sync.
• Leer los campos de una union.

Nada más. La aritmética sigue comprobada, los tipos siguen siendo tipos, el borrow checker sigue vigilando las referencias normales. Y unsafe tiene dos caras gramaticales que conviene no confundir. Una unsafe fn o un unsafe trait exigen: declaran que hay condiciones que el llamador debe cumplir y que el compilador no comprobará. Un bloque unsafe { ... } salda: afirma “yo, aquí, he verificado a mano que esas condiciones se cumplen”. Exigir y saldar: toda la disciplina del unsafe vive en esa asimetría.

let mut v = vec![1, 2, 3];
let p: *mut i32 = v.as_mut_ptr();
// Crear el puntero crudo es seguro; desreferenciarlo, no:
unsafe {
    // SAFETY: p viene de as_mut_ptr, apunta al primer i32, vivo y alineado
    *p = 10;
}

Soundness: el único pecado es dejar que el usuario rompa algo

El objetivo del patrón se formula entonces con precisión quirúrgica: quiero ofrecer una funcionalidad que por dentro necesita unsafe, pero cuya superficie pública sea sound. El usuario podrá llamar a mis métodos en cualquier orden, con cualquier argumento que el tipo admita, y jamás disparará comportamiento indefinido. Si lo consigo, he trasladado toda la carga de la prueba de sus manos a las mías, y la he confinado a un puñado de líneas auditables.

La anatomía: núcleo, invariantes, frontera

Vec<T> es el ejemplo canónico. Por dentro es un (NonNull<T>, usize, usize): puntero, longitud y capacidad. Sus invariantes: el puntero es válido para cap elementos, los primeros len están inicializados, y len <= cap. push escribe en memoria sin inicializar con ptr::write; pop la lee con ptr::read; ambos usan unsafe por dentro. Pero su firma es segura, porque cada método preserva las invariantes. Y los tres campos son privados: por eso no puedes escribir v.len = 9999 y forzar a Vec a leer basura. La privacidad no adorna: es el cerrojo que sostiene la solidez. Basta con exponer un campo para volver unsound toda la abstracción:

pub struct MalVec<T> {
    pub len: usize,   // FATAL: publico rompe la invariante desde codigo seguro
    ptr: NonNull<T>,  // cap y ptr privados no bastan si len es manipulable
    cap: usize,
}

// El usuario, sin escribir una sola linea de unsafe, provoca UB:
//   v.len = 9999;         // miente sobre cuantos elementos hay
//   let x = &v[5000];     // lee memoria sin inicializar -> comportamiento indefinido

No hay unsafe a la vista en el código del usuario, y sin embargo el resultado es UB: eso es precisamente lo que significa que una API sea unsound. La lección es tajante: la frontera de privacidad no es una recomendación de estilo, es parte de la prueba de solidez.

El otro ejemplo revelador es split_at_mut, que parte un &mut [T] en dos mitades mutables disjuntas. El borrow checker no puede demostrar que las mitades no se solapan —no razona sobre índices—, así que la única implementación posible pasa por punteros crudos:

fn split_at_mut<T>(slice: &mut [T], mid: usize) -> (&mut [T], &mut [T]) {
    let len = slice.len();
    let ptr = slice.as_mut_ptr();
    assert!(mid <= len); // la invariante que hace sound al nucleo
    unsafe {
        // SAFETY: mid <= len, luego las dos mitades son disjuntas y caben
        // dentro del slice original; no hay solapamiento ni acceso fuera de rango
        (
            std::slice::from_raw_parts_mut(ptr, mid),
            std::slice::from_raw_parts_mut(ptr.add(mid), len - mid),
        )
    }
}

La firma es 100% segura. El assert! garantiza mid <= len, y de ahí se deduce que las dos mitades no se solapan y caen dentro del slice: por eso el unsafe es correcto. El usuario recibe dos &mut disjuntas y nunca sospecha que hubo punteros crudos de por medio.

flowchart TD
U[Usuario escribe solo codigo seguro] --> API[API publica sin unsafe en la firma]
API --> INV[Invariantes que garantiza el autor]
P[Campos privados] --> INV
INV --> N[Nucleo unsafe pequeno y auditado]
N --> SO[Soundness ningun uso seguro provoca UB]
style U fill:#89b4fa,color:#11111b
style N fill:#f38ba8,color:#11111b
style SO fill:#a6e3a1,color:#11111b
style P fill:#cba6f7,color:#11111b