pub trait Copy: Clone { }
Expand description
Types whose values can be duplicated simply by copying bits.
By default, variable bindings have ‘move semantics.’ In other words:
#[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
, it instead has ‘copy semantics’:
// We can derive a `Copy` implementation. `Clone` is also required, as it's
// a supertrait of `Copy`.
#[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 whether you
are allowed to access x
after the assignment. Under the hood, both a copy and a move
can result in bits being copied in memory, although this is sometimes optimized away.
How can I implement Copy
?
There are two ways to implement Copy
on your type. The simplest is to use derive
:
#[derive(Copy, Clone)]
struct MyStruct;
You can also implement Copy
and Clone
manually:
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
strategy will also place a Copy
bound on type parameters, which isn’t always desired.
What’s the difference between Copy
and Clone
?
Copies happen implicitly, for example as part of an assignment y = x
. The behavior of
Copy
is not overloadable; it is always a simple bit-wise copy.
Cloning is an explicit action, x.clone()
. The implementation of Clone
can
provide any type-specific behavior necessary to duplicate values safely. For example,
the implementation of Clone
for String
needs to copy the pointed-to string
buffer in the heap. A simple bitwise copy of String
values would merely copy the
pointer, leading to a double free down the line. For this reason, String
is Clone
but not Copy
.
Clone
is a supertrait of Copy
, so everything which is Copy
must also implement
Clone
. If a type is Copy
then its Clone
implementation only needs to return *self
(see the example above).
When can my type be Copy
?
A type can implement Copy
if all of its components implement Copy
. For example, this
struct can be Copy
:
#[derive(Copy, Clone)]
struct Point {
x: i32,
y: i32,
}
A struct can be Copy
, and i32
is Copy
, therefore Point
is eligible to be Copy
.
By contrast, consider
struct PointList {
points: Vec<Point>,
}
The struct PointList
cannot implement Copy
, because Vec<T>
is not Copy
. If we
attempt to derive a Copy
implementation, we’ll get an error:
the trait `Copy` may not be implemented for this type; field `points` does not implement `Copy`
Shared references (&T
) are also Copy
, so a type can be Copy
, even when it holds
shared references of types T
that are not Copy
. Consider the following struct,
which can implement Copy
, because it only holds a shared reference to our non-Copy
type PointList
from above:
#[derive(Copy, Clone)]
struct PointListWrapper<'a> {
point_list_ref: &'a PointList,
}
When can’t my type be Copy
?
Some types can’t be copied safely. For example, copying &mut T
would create an aliased
mutable reference. Copying String
would duplicate responsibility for managing the
String
’s buffer, leading to a double free.
Generalizing the latter case, any type implementing Drop
can’t be Copy
, because it’s
managing some resource besides its own size_of::<T>
bytes.
If you try to implement Copy
on a struct or enum containing non-Copy
data, you will get
the error E0204.
When should my type be Copy
?
Generally speaking, if your type can implement Copy
, it should. Keep in mind, though,
that implementing Copy
is part of the public API of your type. If the type might become
non-Copy
in the future, it could be prudent to omit the Copy
implementation now, to
avoid a breaking API change.
Additional implementors
In addition to the implementors listed below,
the following types also implement Copy
:
- Function item types (i.e., the distinct types defined for each function)
- Function pointer types (e.g.,
fn() -> i32
) - Tuple types, if each component also implements
Copy
(e.g.,()
,(i32, bool)
) - Closure types, if they capture no value from the environment
or if all such captured values implement
Copy
themselves. Note that variables captured by shared reference always implementCopy
(even if the referent doesn’t), while variables captured by mutable reference never implementCopy
.
Implementations on Foreign Types
impl Copy for ExitStatus
impl Copy for SocketAddrV4
impl Copy for SeekFrom
impl<'a> Copy for Component<'a>
impl Copy for Shutdown
impl<T> Copy for TrySendError<T> where
T: Copy,
impl Copy for SystemTime
impl Copy for System
impl Copy for Empty
impl Copy for RecvTimeoutError
impl<'a> Copy for IoSlice<'a>
impl Copy for Ipv6Addr
impl Copy for UCred
impl Copy for Instant
impl<'fd> Copy for BorrowedFd<'fd>
impl Copy for FileType
impl Copy for ThreadId
impl Copy for SocketAddrV6
impl<'a> Copy for PrefixComponent<'a>
impl<'a> Copy for Ancestors<'a>
impl Copy for Ipv6MulticastScope
impl<T> Copy for SendError<T> where
T: Copy,
impl Copy for RecvError
impl Copy for IpAddr
impl Copy for WaitTimeoutResult
impl Copy for SocketAddr
impl Copy for ExitStatusError
impl Copy for Ipv4Addr
impl Copy for ExitCode
impl Copy for Sink
impl Copy for BacktraceStyle
impl<'a> Copy for Prefix<'a>
impl Copy for ErrorKind
impl Copy for TryRecvError
impl Copy for AccessError
impl Copy for u64
impl Copy for u32
impl Copy for i8
impl Copy for i128
impl Copy for u8
impl<'_, T> Copy for &'_ T where
T: ?Sized,
Shared references can be copied, but mutable references cannot!