Trait std::marker::Copy [] [src]

pub trait Copy: Clone { }

Types that can be copied by simply copying bits (i.e. memcpy`memcpy`).

By default, variable bindings have 'move semantics.' In other words:

fn main() { #[derive(Debug)] struct Foo; let x = Foo; let y = x; // `x` has moved into `y`, and so cannot be used // println!("{:?}", x); // error: use of moved value }
#[derive(Debug)]
struct Foo;

let x = Foo;

let y = x;

// `x` has moved into `y`, and so cannot be used

// println!("{:?}", x); // error: use of moved value

However, if a type implements Copy`Copy`, it instead has 'copy semantics':

fn main() { // we can just derive a `Copy` implementation #[derive(Debug, Copy, Clone)] struct Foo; let x = Foo; let y = x; // `y` is a copy of `x` println!("{:?}", x); // A-OK! }
// we can just derive a `Copy` implementation
#[derive(Debug, Copy, Clone)]
struct Foo;

let x = Foo;

let y = x;

// `y` is a copy of `x`

println!("{:?}", x); // A-OK!

It's important to note that in these two examples, the only difference is if you are allowed to access x`x` after the assignment: a move is also a bitwise copy under the hood.

When can my type be Copy`Copy`?

A type can implement Copy`Copyif all of its components implement` if all of its components implement Copy`Copy. For example, this`. For example, this struct`structcan be` can be Copy`Copy`:

fn main() { struct Point { x: i32, y: i32, } }
struct Point {
   x: i32,
   y: i32,
}

A struct`structcan be` can be Copy`Copy, and`, and i32`i32is` is Copy`Copy, so therefore,`, so therefore, Point`Pointis eligible to be` is eligible to be Copy`Copy`.

fn main() { struct Point; struct PointList { points: Vec<Point>, } }
struct PointList {
    points: Vec<Point>,
}

The PointList`PointList` struct`structcannot implement` cannot implement Copy`Copy, because`, because Vec<T>`Vecis not` is not Copy`Copy. If we attempt to derive a`. If we attempt to derive a Copy`Copy` implementation, we'll get an error.

error: the trait `Copy` may not be implemented for this type; field `points` does not implement
`Copy`

How can I implement Copy`Copy`?

There are two ways to implement Copy`Copy` on your type:

fn main() { #[derive(Copy, Clone)] struct MyStruct; }
#[derive(Copy, Clone)]
struct MyStruct;

and

fn main() { struct MyStruct; impl Copy for MyStruct {} impl Clone for MyStruct { fn clone(&self) -> MyStruct { *self } } }
struct MyStruct;
impl Copy for MyStruct {}
impl Clone for MyStruct { fn clone(&self) -> MyStruct { *self } }

There is a small difference between the two: the derive`derivestrategy will also place a` strategy will also place a Copy`Copy` bound on type parameters, which isn't always desired.

When can my type not be Copy`Copy`?

Some types can't be copied safely. For example, copying &mut T`&mut Twould create an aliased mutable reference, and copying` would create an aliased mutable reference, and copying String`String` would result in two attempts to free the same buffer.

Generalizing the latter case, any type implementing Drop`Dropcan't be` can't be Copy`Copy, because it's managing some resource besides its own`, because it's managing some resource besides its own size_of::<T>()`size_of::()` bytes.

When should my type be Copy`Copy`?

Generally speaking, if your type can implement Copy`Copy, it should. There's one important thing to consider though: if you think your type may _not_ be able to implement`, it should. There's one important thing to consider though: if you think your type may not be able to implement Copy`Copyin the future, then it might be prudent to not implement` in the future, then it might be prudent to not implement Copy`Copy. This is because removing`. This is because removing Copy`Copyis a breaking change: that second example would fail to compile if we made` is a breaking change: that second example would fail to compile if we made Foo`Foonon-` non-Copy`Copy`.

Implementors