Clone in std::clone - Rust (original) (raw)
Trait Clone
1.0.0 · Source
pub trait Clone: Sized {
// Required method
fn clone(&self) -> Self;
// Provided method
fn clone_from(&mut self, source: &Self) { ... }
}
Expand description
A common trait for the ability to explicitly duplicate an object.
Differs from Copy in that Copy is implicit and an inexpensive bit-wise copy, whileClone
is always explicit and may or may not be expensive. In order to enforce these characteristics, Rust does not allow you to reimplement Copy, but you may reimplement Clone
and run arbitrary code.
Since Clone
is more general than Copy, you can automatically make anythingCopy be Clone
as well.
§Derivable
This trait can be used with #[derive]
if all fields are Clone
. The derive
d implementation of Clone calls clone on each field.
For a generic struct, #[derive]
implements Clone
conditionally by adding bound Clone
on generic parameters.
// `derive` implements Clone for Reading<T> when T is Clone.
#[derive(Clone)]
struct Reading<T> {
frequency: T,
}
§How can I implement Clone
?
Types that are Copy should have a trivial implementation of Clone
. More formally: if T: Copy
, x: T
, and y: &T
, then let x = y.clone();
is equivalent to let x = *y;
. Manual implementations should be careful to uphold this invariant; however, unsafe code must not rely on it to ensure memory safety.
An example is a generic struct holding a function pointer. In this case, the implementation of Clone
cannot be derive
d, but can be implemented as:
struct Generate<T>(fn() -> T);
impl<T> Copy for Generate<T> {}
impl<T> Clone for Generate<T> {
fn clone(&self) -> Self {
*self
}
}
If we derive
:
#[derive(Copy, Clone)]
struct Generate<T>(fn() -> T);
the auto-derived implementations will have unnecessary T: Copy
and T: Clone
bounds:
// Automatically derived
impl<T: Copy> Copy for Generate<T> { }
// Automatically derived
impl<T: Clone> Clone for Generate<T> {
fn clone(&self) -> Generate<T> {
Generate(Clone::clone(&self.0))
}
}
The bounds are unnecessary because clearly the function itself should be copy- and cloneable even if its return type is not:
#[derive(Copy, Clone)]
struct Generate<T>(fn() -> T);
struct NotCloneable;
fn generate_not_cloneable() -> NotCloneable {
NotCloneable
}
Generate(generate_not_cloneable).clone(); // error: trait bounds were not satisfied
// Note: With the manual implementations the above line will compile.
§Additional implementors
In addition to the implementors listed below, the following types also implement Clone
:
- Function item types (i.e., the distinct types defined for each function)
- Function pointer types (e.g.,
fn() -> i32
) - Closure types, if they capture no value from the environment or if all such captured values implement
Clone
themselves. Note that variables captured by shared reference always implementClone
(even if the referent doesn’t), while variables captured by mutable reference never implementClone
.
1.0.0 · Source
Returns a copy of the value.
§Examples
let hello = "Hello"; // &str implements Clone
assert_eq!("Hello", hello.clone());
1.0.0 · Source
Performs copy-assignment from source
.
a.clone_from(&b)
is equivalent to a = b.clone()
in functionality, but can be overridden to reuse the resources of a
to avoid unnecessary allocations.
This trait is not dyn compatible.
In older versions of Rust, dyn compatibility was called "object safety", so this trait is not object safe.