Il tratto Copy ha avuto origine nel design iniziale di Rust come un marcatore per i tipi che possono essere duplicati tramite una semplice copia bitwise senza preoccupazioni di gestione delle risorse. Drop è stato introdotto per gestire la pulizia delle risorse in modo deterministico per i tipi che gestiscono risorse esterne come descrittori di file o memoria heap. Il conflitto tra duplicazione implicita e proprietà unica è diventato evidente quando i progettisti si sono resi conto che le copie bitwise avrebbero condiviso gestori di risorse non condivisibili. Di conseguenza, il compilatore è stato progettato per rifiutare qualsiasi tipo che tenta di implementare entrambi i tratti simultaneamente.
Se un tipo che implementa Drop (ad es., gestendo un descrittore di file) fosse anche Copy, assegnare il valore a una nuova variabile creerebbe due copie bitwise-identiche. Quando entrambe le copie escono dallo scope, l'implementazione personalizzata di Drop viene eseguita due volte sulla stessa risorsa sottostante. Ciò porta a una vulnerabilità di double-free o use-after-free se la risorsa viene invalidata dal primo drop ma viene acceduta dal secondo, comprometttendo la sicurezza della memoria.
Il compilatore Rust include un controllo di coerenza nel sistema dei tratti che esplicitamente vieta a un tipo di implementare sia Copy che Drop. Questa restrizione costringe gli sviluppatori a utilizzare Clone (duplicazione esplicita) per i tipi che richiedono una distruzione personalizzata, consentendo all'implementazione di incrementare correttamente i conteggi di riferimento o di eseguire copie profonde. Garantendo che ogni entità logica abbia un corrispondente drop unico, il sistema di tipi mantiene astrazioni a costo zero senza sacrificare le garanzie di sicurezza.
Considera una struct DatabaseHandle che avvolge un puntatore raw a un oggetto di connessione in una libreria C esterna. L'applicazione richiede di passare i gestori per valore in più chiusure per il logging, eppure ogni gestore deve chiudere la propria connessione unica tramite una chiamata FFI quando viene dropped. Se il gestore fosse Copy, la duplicazione implicita creerebbe più gestori che rivendicano la proprietà della stessa risorsa C sottostante, causando inevitabilmente chiusure doppie o use-after-free quando lo scope esce.
Un approccio era consentire Copy e implementare Drop con conteggio di riferimento interno utilizzando Arc. Questo avrebbe aggiunto un overhead di sincronizzazione per ogni gestore, aumentando le dimensioni del binario e il costo di runtime per tutte le operazioni. Complicava anche il confine FFI dove il puntatore raw deve essere estratto in modo atomico da Arc, introducendo potenziali deadlock se la logica di drop stessa chiama nuovamente del codice Rust.
Un altro approccio prevedeva l'utilizzo di Copy ma documentava che gli utenti dovevano chiamare manualmente un metodo close prima che il valore fosse dropped. Questo poneva l'onere della sicurezza della memoria interamente sul programmatore, violando il principio fondamentale di Rust di prevenire errori al momento della compilazione. Portava inevitabilmente a perdite di risorse quando gli sviluppatori dimenticavano di chiamare close, o a chiusure doppie quando copiavano il gestore involontariamente e tentavano di chiudere entrambe le copie.
La soluzione scelta è stata rimuovere Copy e implementare manualmente Clone, insieme a Drop. Clone esegue una copia profonda aprendo una nuova connessione al database, garantendo che ogni istanza possieda la propria risorsa distinta e prevenendo l'aliasing del puntatore C sottostante. Drop chiude solo la propria connessione, mentre il compilatore previene copie bitwise accidentali, mantenendo la sicurezza senza overhead di runtime.
Il sistema di tipi ora previene copie accidentali al momento della compilazione, costringendo gli sviluppatori a chiamare esplicitamente clone e rendendo visibile l'acquisizione delle risorse nel codice sorgente. Il programma evita errori di double-free quando i gestori vengono passati in thread o chiusure, e le garanzie di distruzione deterministica rimangono intatte senza richiedere operazioni atomiche o gestione manuale della memoria.
Perché non posso derivare Copy per una struct contenente un Vec?
Un Vec possiede memoria allocata nell'heap e implementa Drop per liberare quella memoria quando il vettore esce dallo scope. Se una struct contenente un Vec fosse Copy, la duplicazione bitwise creerebbe due struct che puntano allo stesso buffer heap nello stack, ma entrambe conterrebbero lo stesso puntatore all'heap. Quando la prima struct viene dropped, la memoria viene liberata; quando la seconda viene dropped, tenta di liberare la stessa memoria di nuovo, causando un comportamento indefinito. Rust previene questo richiedendo che tutti i campi di un tipo Copy siano anch'essi Copy, garantendo ricorsivamente che non esistano implementazioni di Drop annidate.
std::mem::forget evita i problemi con Copy e Drop?
std::mem::forget consuma un valore senza eseguire il suo distruttore, ma influisce solo su un valore specifico posseduto, non su tutte le sue copie. Se Copy e Drop fossero consentiti, dimenticare una copia non impedirebbe ad altre copie bitwise di eseguire le loro implementazioni di Drop quando escono dallo scope. Quei residui di drop tenterebbero ancora di rilasciare la stessa risorsa sottostante, portando a use-after-free o double-free indipendentemente dall'istanza dimenticata.
Posso usare ManuallyDrop per implementare Copy in modo sicuro?
Avvolgere un campo in ManuallyDrop impedisce l'invocazione automatica di Drop, il che consente tecnicamente alla struct esterna di derivare Copy. Tuttavia, ciò sposta la responsabilità di chiamare ManuallyDrop::drop all'utente per ogni singola copia creata, creando effettivamente uno scenario di gestione manuale della memoria. Se l'utente dimentica di rimuovere anche una copia, la risorsa si perde permanentemente; Rust vieta questo pattern per i tipi che possiedono risorse perché mina la garanzia di sicurezza di pulizia automatica e deterministica.