Clone y Copy: la copia profunda y la duplicación de bits

Ya sabes que asignar un String lo mueve e invalida el original, mientras que asignar un i32 deja los dos válidos. Detrás de esa diferencia hay dos traits: Clone, la copia profunda que pides a mano, y Copy, la duplicación implícita que Rust hace por ti para los tipos triviales. Parecen dos formas de lo mismo, pero encierran una de las ideas más finas del lenguaje: mover y copiar son, para la máquina, la misma operación; lo único que cambia es qué le pasa al original después.

Clone: la copia profunda explícita

Clone añade el método .clone(), que produce un duplicado completamente independiente, incluida la memoria del heap que el valor posea.

#[derive(Debug, Clone)]
struct Perfil {
    nombre: String,
    etiquetas: Vec<String>,
}

fn main() {
    let a = Perfil { nombre: String::from("Ada"), etiquetas: vec![String::from("phd")] };
    let b = a.clone();   // copia PROFUNDA: reserva nuevo heap para el String y el Vec
    // 'a' sigue siendo válido; 'a' y 'b' no comparten ni un byte del heap
    println!("{a:?} / {b:?}");
}

Que Clone sea explícito es intencional. Clonar un String o un Vec reserva memoria y copia su contenido: es un coste real, potencialmente grande. Rust te obliga a escribir .clone() para que ese coste sea visible en el código; nunca ocurre a tus espaldas. El derive genera un impl que clona campo a campo, así que la capacidad viaja recursivamente: Perfil puede derivar Clone porque String y Vec<String> ya lo son.

Copy: la duplicación implícita del stack

Copy es un trait marcador: no añade ningún método. Lo que hace es cambiar la semántica del lenguaje para ese tipo. Con Copy, la asignación deja de mover y pasa a duplicar los bits, y el original sigue vivo.

#[derive(Debug, Clone, Copy)]
struct Punto {
    x: i32,
    y: i32,
}

fn main() {
    let p = Punto { x: 1, y: 2 };
    let q = p;             // COPIA implícita de bits; 'p' NO se invalida
    println!("{p:?} {q:?}"); // ambos validos
}

Los tipos Copy son los triviales: enteros, f64, bool, char, y structs cuyos campos son todos Copy. Duplicarlos es copiar unos pocos bytes del stack, sin reservar memoria ni ejecutar ninguna lógica. Por eso Rust puede hacerlo implícitamente sin sorpresas de rendimiento: no hay coste oculto que esconder.

Nota que Copy requiere Clone (Copy: Clone): todo tipo Copy es también Clone, y su .clone() es simplemente esa copia de bits. Por eso los ves derivados juntos.

Por qué no todo puede ser Copy

Aquí está el límite duro. Un tipo puede ser Copy solo si todos sus campos lo son, y jamás si posee un recurso del heap. La razón no es una regla arbitraria, sino la seguridad de memoria.

Imagina que String fuera Copy. Entonces let b = a; copiaría los bits del String: el puntero al heap, la longitud y la capacidad. Ahora a y b contendrían el mismo puntero al mismo búfer, y ambos seguirían válidos. Cuando cada uno se destruyera al final del scope, cada uno liberaría ese búfer: un doble free, corrupción de memoria clásica. Copy significa exactamente “duplicar este valor es copiar sus bits, sin ninguna lógica de propiedad”; un tipo que posee memoria no cumple esa promesa, y por eso el lenguaje se lo prohíbe.

La revelación: move y Copy son la misma copia de bits

Casi todo el mundo cree que mover y copiar son operaciones distintas a nivel de máquina. No lo son. Tanto let b = a; cuando a es un String (move) como cuando a es un Punto (Copy) hacen exactamente lo mismo en el procesador: un memcpy de los bytes de a a b. Para un String, esos bytes son el puntero, la longitud y la capacidad —el heap no se toca—; para un Punto, son sus dos enteros.

La única diferencia entre move y Copy es qué le pasa al origen después de la copia de bits:

flowchart TD
A[let b igual a a] --> C[memcpy de los bits de a hacia b]
C --> Q[El tipo es Copy]
Q -->|no| M[Move: el origen a queda invalidado]
Q -->|si| K[Copy: el origen a sigue valido]
M --> S[Un unico dueno de la memoria]
K --> D[Dos valores independientes sin heap compartido]
style M fill:#f38ba8,color:#11111b
style K fill:#a6e3a1,color:#11111b
style S fill:#89b4fa,color:#11111b
style D fill:#cba6f7,color:#11111b

Por eso Copy solo es seguro para tipos sin heap: si los bits copiados incluyeran un puntero a memoria poseída, dejar vivo el origen crearía dos dueños del mismo búfer. Copy no es “una copia más barata que Clone”; es la afirmación de que dejar vivo el original tras la copia de bits es seguro.