DerefMut y la transparencia de Box, Rc y compañía

Deref hizo que un puntero se pudiera leer a su través; DerefMut hace que se pueda escribir. Juntos convierten a Box<T> en algo transparente: se comporta como un T para leer, para llamar a sus métodos y para asignarle un valor nuevo. Pero no todos los punteros inteligentes implementan DerefMut, y la ausencia es tan significativa como la presencia: Rc<T> y Arc<T> se quedan solo en Deref, porque la propiedad compartida hace imposible entregar un &mut seguro. Que un puntero te deje mutar a su través es una afirmación a nivel de tipo, decidida en compilación, no una propiedad de tiempo de ejecución.

DerefMut: escribir a través del puntero

DerefMut tiene a Deref como supertrait: no puedes implementar el mutable sin el compartido. Su método devuelve una referencia mutable al Target:

pub trait DerefMut: Deref {
    fn deref_mut(&mut self) -> &mut Self::Target;
}

Con él, *x = valor se expande a *x.deref_mut() = valor, y &mut *x te da acceso mutable al interior. Que DerefMut exija Deref no es burocracia: garantiza que el Target mutable y el compartido son el mismo tipo, de modo que leer y escribir apuntan al mismo lugar.

Box es transparente para leer y para escribir

Box<T> implementa ambos traits, así que desaparece en el punto de uso: puedes llamar métodos &self y &mut self del interior, indexar y reasignar el valor entero.

fn main() {
    let mut b = Box::new(vec![1, 2, 3]);
    b.push(4);         // metodo &mut self de Vec, alcanzado por DerefMut
    b[0] = 10;         // asignacion a traves del Box (Index + DerefMut)
    *b = vec![9];      // reasigna el Vec entero, via deref_mut
    println!("{b:?}"); // [9]
}

En ningún momento escribes .deref() ni .deref_mut(): el compilador los inserta al resolver métodos y al desazucarar el *. La caja es, a efectos de uso, el Vec que contiene.

Rc y Arc: Deref sí, DerefMut no

Aquí la ausencia habla. Rc<T> (contador de referencias de un solo hilo) y Arc<T> (su versión atómica, entre hilos) permiten varios dueños del mismo valor. Si implementaran DerefMut, podrías obtener un &mut T mientras otro Rc observa el mismo T: dos accesos, uno de ellos mutable, al mismo dato —precisamente el aliasing que las reglas de préstamo prohíben—. Por eso solo implementan Deref:

use std::rc::Rc;

fn main() {
    let compartido = Rc::new(5);
    let _otro = Rc::clone(&compartido);   // dos duenos: hay aliasing
    println!("{}", *compartido);          // leer a traves: OK, via Deref
    // *compartido = 6;                    // ERROR: Rc no implementa DerefMut
}

Para mutar un valor con varios dueños necesitas mutabilidad interior: trasladar la comprobación del aliasing a tiempo de ejecución con RefCell (un hilo) o Mutex (varios hilos), envueltos dentro del Rc o del Arc.

use std::rc::Rc;
use std::cell::RefCell;

fn main() {
    let compartido = Rc::new(RefCell::new(5));
    *compartido.borrow_mut() += 1;         // RefMut SI implementa DerefMut
    assert_eq!(*compartido.borrow(), 6);
}

Los guardas: DerefMut con disciplina

El patrón de borrow_mut revela quién hace el trabajo. RefCell no implementa DerefMut; te entrega un guarda, un valor temporal (Ref o RefMut) que sí lo implementa y que, al morir, devuelve el préstamo. Lo mismo hacen los cerrojos: Mutex::lock da un MutexGuard que implementa DerefMut, y RwLock reparte un guarda de lectura (solo Deref) y uno de escritura (DerefMut).

flowchart TB
P[Puntero inteligente] --> Q[Garantiza acceso exclusivo]
Q -->|si Box y guardas| M[Implementa Deref y DerefMut]
Q -->|no Rc y Arc| R[Implementa solo Deref]
M --> W[Puedes leer y escribir a traves]
R --> L[Solo lectura a traves]
L --> I[Para mutar usa RefCell o Mutex dentro]
style M fill:#a6e3a1,color:#11111b
style R fill:#f38ba8,color:#11111b
style W fill:#89b4fa,color:#11111b
style I fill:#cba6f7,color:#11111b

Así, *guard += 1 funciona por el DerefMut del guarda, y el Drop del guarda suelta el cerrojo o cierra el préstamo. La transparencia mutable y la liberación determinista trabajan juntas.