Answer.

Let's consider the history of the issue:

In Rust, the concept of memory management and ownership requires a clear definition of how objects are moved and copied. In the early days of the language, it was important to distinguish between simple byte copying (without allocations and logic) and deep cloning (for example, a copy of a string, vector). For this, two traits were introduced — Copy and Clone.

The problem is that not all data types are equally cheap to copy. For some structures, copying is just a copy of bits (e.g., integers or tuples of Copy types), while for others (e.g., String, Vec) there is additional work for memory allocation. The separation of Copy and Clone allows Rust to issue a compile-time error if an invalid copy attempt is made.

Solution:

Types marked as Copy are automatically copied when passed, assigned, and transferred to functions. Objects of such types remain valid after copying.
For complex objects, Clone is implemented, which assumes an explicit call to the .clone() method, often with additional resource allocation.

Code example:

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

fn main() {
    let p1 = Point { x: 1, y: 2 };
    let p2 = p1; // p1 does not become "invalid"
    println!("{:?} {:?}", p1, p2);
}

Key features:

Copy - automatic bitwise copying, does not require manual calls and does not affect ownership.
Clone - explicit deep copying, suitable for structures with heap data.
Both traits can be implemented manually, but Copy has strict limitations (all fields must be Copy).

Trick questions.

Can types with heap-allocated data have Copy derivation?

No, types that contain heap data (e.g., String, Vec) cannot automatically implement Copy, as this would lead to double memory freeing.

If a type implements Copy, can it also implement Clone manually with different logic?

Yes, Clone can be implemented manually and the logic can differ, however, it is recommended that Copy and Clone be consistent: Copy simply calls Clone without allocations.

#[derive(Copy)]
struct X;
impl Clone for X {
    fn clone(&self) -> X { *self }
}

If a struct contains only Copy fields but is not marked #[derive(Copy)], will it be Copy?

No, a type does not automatically become Copy due to its composition — explicit Copy derivation is required for your type.

Common mistakes and anti-patterns

Incorrectly implementing Copy for types with heap-allocated fields.
Attempting to use an instance of a non-Copy type after a move.
Implementing Copy and forgetting to implement Clone, violating API client expectations.

Real-life example

Negative case

A type with heap data is incorrectly marked as Copy; double memory freeing occurs during finalization.

Pros:

The compiler will not allow it, but with unsafe code, detection errors are possible.

Cons:

Application crash.

Positive case

Using Copy for lightweight structures (coordinates, colors), Clone — for complex ones (strings, vectors). The code is safe and predictable.