The Copy trait originated in Rust's early design as a marker for types that can be duplicated via simple bitwise copy without resource management concerns. Drop was introduced to handle deterministic resource cleanup for types managing external resources like file descriptors or heap memory. The conflict between implicit duplication and unique ownership became apparent when designers realized that bitwise copies would share non-shareable resource handles. Consequently, the compiler was architected to reject any type that attempts to implement both traits simultaneously.
If a type implementing Drop (e.g., managing a file descriptor) were also Copy, assigning the value to a new variable would create two bitwise-identical copies. When both copies go out of scope, the custom Drop implementation executes twice on the same underlying resource. This leads to a double-free vulnerability or use-after-free if the resource is invalidated by the first drop but accessed by the second, compromising memory safety.
The Rust compiler includes a coherence check in the trait system that explicitly forbids a type from implementing both Copy and Drop. This constraint forces developers to use Clone (explicit duplication) for types requiring custom destruction, allowing the implementation to properly increment reference counts or perform deep copies. By ensuring each logical entity has a corresponding unique drop, the type system maintains zero-cost abstractions without sacrificing safety guarantees.
Consider a DatabaseHandle struct wrapping a raw pointer to a connection object in an external C library. The application requires passing handles by value into multiple closures for logging, yet each handle must close its unique connection via an FFI call when dropped. If the handle were Copy, implicit duplication would create multiple handles claiming ownership of the same underlying C resource, inevitably causing double-closes or use-after-free when the scope exits.
One approach was to allow Copy and implement Drop with internal reference counting using Arc. This would add synchronization overhead for every handle, increasing binary size and runtime cost across all operations. It also complicates the FFI boundary where the raw pointer must be atomically extracted from the Arc, introducing potential deadlocks if the drop logic itself calls back into Rust code.
Another approach involved using Copy but documenting that users must call a close method manually before the value is dropped. This places the burden of memory safety entirely on the programmer, violating Rust's core principle of preventing errors at compile time. It inevitably leads to resource leaks when developers forget to call close, or to double-closes when they copy the handle inadvertently and attempt to close both copies.
The chosen solution was to remove Copy and implement Clone manually, along with Drop. Clone performs a deep copy by opening a new database connection, ensuring each instance owns its distinct resource and preventing aliasing of the underlying C pointer. Drop closes only its own connection, while the compiler prevents accidental bitwise copies, maintaining safety without runtime overhead.
The type system now prevents accidental copying at compile time, forcing developers to explicitly call clone and making resource acquisition visible in the source code. The program avoids double-free errors when handles are passed into threads or closures, and the deterministic destruction guarantees remain intact without requiring atomic operations or manual memory management.
Why can't I derive Copy for a struct containing a Vec?
A Vec owns heap-allocated memory and implements Drop to free that memory when the vector goes out of scope. If a struct containing a Vec were Copy, bitwise duplication would create two structs pointing to the same heap buffer on the stack, but both would contain the same pointer to the heap. When the first struct is dropped, the memory is freed; when the second is dropped, it attempts to free the same memory again, causing undefined behavior. Rust prevents this by requiring all fields of a Copy type to also be Copy, recursively ensuring no nested Drop implementations exist.
Does mem::forget prevent the issues with Copy and Drop?
std::mem::forget consumes a value without running its destructor, but it only affects one specific owned value, not all copies of it. If Copy and Drop were allowed, forgetting one copy would not prevent other bitwise copies from executing their Drop implementations when they go out of scope. Those remaining drops would still attempt to release the same underlying resource, leading to use-after-free or double-free regardless of the forgotten instance.
Can I use ManuallyDrop to implement Copy safely?
Wrapping a field in ManuallyDrop prevents the automatic invocation of Drop, which technically allows the outer struct to derive Copy. However, this shifts the responsibility of calling ManuallyDrop::drop to the user for every single copy created, effectively creating a manual memory management scenario. If the user forgets to drop even one copy, the resource leaks permanently; Rust forbids this pattern for resource-owning types because it undermines the safety guarantee of deterministic, automatic cleanup.