core/clone.rs
1//! The `Clone` trait for types that cannot be 'implicitly copied'.
2//!
3//! In Rust, some simple types are "implicitly copyable" and when you
4//! assign them or pass them as arguments, the receiver will get a copy,
5//! leaving the original value in place. These types do not require
6//! allocation to copy and do not have finalizers (i.e., they do not
7//! contain owned boxes or implement [`Drop`]), so the compiler considers
8//! them cheap and safe to copy. For other types copies must be made
9//! explicitly, by convention implementing the [`Clone`] trait and calling
10//! the [`clone`] method.
11//!
12//! [`clone`]: Clone::clone
13//!
14//! Basic usage example:
15//!
16//! ```
17//! let s = String::new(); // String type implements Clone
18//! let copy = s.clone(); // so we can clone it
19//! ```
20//!
21//! To easily implement the Clone trait, you can also use
22//! `#[derive(Clone)]`. Example:
23//!
24//! ```
25//! #[derive(Clone)] // we add the Clone trait to Morpheus struct
26//! struct Morpheus {
27//! blue_pill: f32,
28//! red_pill: i64,
29//! }
30//!
31//! fn main() {
32//! let f = Morpheus { blue_pill: 0.0, red_pill: 0 };
33//! let copy = f.clone(); // and now we can clone it!
34//! }
35//! ```
36
37#![stable(feature = "rust1", since = "1.0.0")]
38
39use crate::marker::{Destruct, PointeeSized};
40
41mod uninit;
42
43/// A common trait that allows explicit creation of a duplicate value.
44///
45/// Calling [`clone`] always produces a new value.
46/// However, for types that are references to other data (such as smart pointers or references),
47/// the new value may still point to the same underlying data, rather than duplicating it.
48/// See [`Clone::clone`] for more details.
49///
50/// This distinction is especially important when using `#[derive(Clone)]` on structs containing
51/// smart pointers like `Arc<Mutex<T>>` - the cloned struct will share mutable state with the
52/// original.
53///
54/// Differs from [`Copy`] in that [`Copy`] is implicit and an inexpensive bit-wise copy, while
55/// `Clone` is always explicit and may or may not be expensive. [`Copy`] has no methods, so you
56/// cannot change its behavior, but when implementing `Clone`, the `clone` method you provide
57/// may run arbitrary code.
58///
59/// Since `Clone` is a supertrait of [`Copy`], any type that implements `Copy` must also implement
60/// `Clone`.
61///
62/// ## Derivable
63///
64/// This trait can be used with `#[derive]` if all fields are `Clone`. The `derive`d
65/// implementation of [`Clone`] calls [`clone`] on each field.
66///
67/// [`clone`]: Clone::clone
68///
69/// For a generic struct, `#[derive]` implements `Clone` conditionally by adding bound `Clone` on
70/// generic parameters.
71///
72/// ```
73/// // `derive` implements Clone for Reading<T> when T is Clone.
74/// #[derive(Clone)]
75/// struct Reading<T> {
76/// frequency: T,
77/// }
78/// ```
79///
80/// ## How can I implement `Clone`?
81///
82/// Types that are [`Copy`] should have a trivial implementation of `Clone`. More formally:
83/// if `T: Copy`, `x: T`, and `y: &T`, then `let x = y.clone();` is equivalent to `let x = *y;`.
84/// Manual implementations should be careful to uphold this invariant; however, unsafe code
85/// must not rely on it to ensure memory safety.
86///
87/// An example is a generic struct holding a function pointer. In this case, the
88/// implementation of `Clone` cannot be `derive`d, but can be implemented as:
89///
90/// ```
91/// struct Generate<T>(fn() -> T);
92///
93/// impl<T> Copy for Generate<T> {}
94///
95/// impl<T> Clone for Generate<T> {
96/// fn clone(&self) -> Self {
97/// *self
98/// }
99/// }
100/// ```
101///
102/// If we `derive`:
103///
104/// ```
105/// #[derive(Copy, Clone)]
106/// struct Generate<T>(fn() -> T);
107/// ```
108///
109/// the auto-derived implementations will have unnecessary `T: Copy` and `T: Clone` bounds:
110///
111/// ```
112/// # struct Generate<T>(fn() -> T);
113///
114/// // Automatically derived
115/// impl<T: Copy> Copy for Generate<T> { }
116///
117/// // Automatically derived
118/// impl<T: Clone> Clone for Generate<T> {
119/// fn clone(&self) -> Generate<T> {
120/// Generate(Clone::clone(&self.0))
121/// }
122/// }
123/// ```
124///
125/// The bounds are unnecessary because clearly the function itself should be
126/// copy- and cloneable even if its return type is not:
127///
128/// ```compile_fail,E0599
129/// #[derive(Copy, Clone)]
130/// struct Generate<T>(fn() -> T);
131///
132/// struct NotCloneable;
133///
134/// fn generate_not_cloneable() -> NotCloneable {
135/// NotCloneable
136/// }
137///
138/// Generate(generate_not_cloneable).clone(); // error: trait bounds were not satisfied
139/// // Note: With the manual implementations the above line will compile.
140/// ```
141///
142/// ## `Clone` and `PartialEq`/`Eq`
143/// `Clone` is intended for the duplication of objects. Consequently, when implementing
144/// both `Clone` and [`PartialEq`], the following property is expected to hold:
145/// ```text
146/// x == x -> x.clone() == x
147/// ```
148/// In other words, if an object compares equal to itself,
149/// its clone must also compare equal to the original.
150///
151/// For types that also implement [`Eq`] – for which `x == x` always holds –
152/// this implies that `x.clone() == x` must always be true.
153/// Standard library collections such as
154/// [`HashMap`], [`HashSet`], [`BTreeMap`], [`BTreeSet`] and [`BinaryHeap`]
155/// rely on their keys respecting this property for correct behavior.
156/// Furthermore, these collections require that cloning a key preserves the outcome of the
157/// [`Hash`] and [`Ord`] methods. Thankfully, this follows automatically from `x.clone() == x`
158/// if `Hash` and `Ord` are correctly implemented according to their own requirements.
159///
160/// When deriving both `Clone` and [`PartialEq`] using `#[derive(Clone, PartialEq)]`
161/// or when additionally deriving [`Eq`] using `#[derive(Clone, PartialEq, Eq)]`,
162/// then this property is automatically upheld – provided that it is satisfied by
163/// the underlying types.
164///
165/// Violating this property is a logic error. The behavior resulting from a logic error is not
166/// specified, but users of the trait must ensure that such logic errors do *not* result in
167/// undefined behavior. This means that `unsafe` code **must not** rely on this property
168/// being satisfied.
169///
170/// ## Additional implementors
171///
172/// In addition to the [implementors listed below][impls],
173/// the following types also implement `Clone`:
174///
175/// * Function item types (i.e., the distinct types defined for each function)
176/// * Function pointer types (e.g., `fn() -> i32`)
177/// * Closure types, if they capture no value from the environment
178/// or if all such captured values implement `Clone` themselves.
179/// Note that variables captured by shared reference always implement `Clone`
180/// (even if the referent doesn't),
181/// while variables captured by mutable reference never implement `Clone`.
182///
183/// [`HashMap`]: ../../std/collections/struct.HashMap.html
184/// [`HashSet`]: ../../std/collections/struct.HashSet.html
185/// [`BTreeMap`]: ../../std/collections/struct.BTreeMap.html
186/// [`BTreeSet`]: ../../std/collections/struct.BTreeSet.html
187/// [`BinaryHeap`]: ../../std/collections/struct.BinaryHeap.html
188/// [impls]: #implementors
189#[stable(feature = "rust1", since = "1.0.0")]
190#[lang = "clone"]
191#[rustc_diagnostic_item = "Clone"]
192#[rustc_trivial_field_reads]
193#[rustc_const_unstable(feature = "const_clone", issue = "142757")]
194pub const trait Clone: Sized {
195 /// Returns a duplicate of the value.
196 ///
197 /// Note that what "duplicate" means varies by type:
198 /// - For most types, this creates a deep, independent copy
199 /// - For reference types like `&T`, this creates another reference to the same value
200 /// - For smart pointers like [`Arc`] or [`Rc`], this increments the reference count
201 /// but still points to the same underlying data
202 ///
203 /// [`Arc`]: ../../std/sync/struct.Arc.html
204 /// [`Rc`]: ../../std/rc/struct.Rc.html
205 ///
206 /// # Examples
207 ///
208 /// ```
209 /// # #![allow(noop_method_call)]
210 /// let hello = "Hello"; // &str implements Clone
211 ///
212 /// assert_eq!("Hello", hello.clone());
213 /// ```
214 ///
215 /// Example with a reference-counted type:
216 ///
217 /// ```
218 /// use std::sync::{Arc, Mutex};
219 ///
220 /// let data = Arc::new(Mutex::new(vec![1, 2, 3]));
221 /// let data_clone = data.clone(); // Creates another Arc pointing to the same Mutex
222 ///
223 /// {
224 /// let mut lock = data.lock().unwrap();
225 /// lock.push(4);
226 /// }
227 ///
228 /// // Changes are visible through the clone because they share the same underlying data
229 /// assert_eq!(*data_clone.lock().unwrap(), vec![1, 2, 3, 4]);
230 /// ```
231 #[stable(feature = "rust1", since = "1.0.0")]
232 #[must_use = "cloning is often expensive and is not expected to have side effects"]
233 // Clone::clone is special because the compiler generates MIR to implement it for some types.
234 // See InstanceKind::CloneShim.
235 #[lang = "clone_fn"]
236 fn clone(&self) -> Self;
237
238 /// Performs copy-assignment from `source`.
239 ///
240 /// `a.clone_from(&b)` is equivalent to `a = b.clone()` in functionality,
241 /// but can be overridden to reuse the resources of `a` to avoid unnecessary
242 /// allocations.
243 #[inline]
244 #[stable(feature = "rust1", since = "1.0.0")]
245 fn clone_from(&mut