Rollup merge of #150139 - GKFX:clone-docs, r=jhpratt
Correct terminology in Clone I think the current wording around Clone here is confusing: - "Rust does not allow you to reimplement `Copy`" - reimplement isn't a piece of Rust terminology, but as written it sounds like you can't write `impl Copy for X`, which you can. - "you may reimplement `Clone`" - again reimplement isn't really a thing that you do to a trait, the distinction is between manually implementing and deriving. - "you can automatically make anything `Copy` be `Clone` as well" - you don't have a choice about it, so it doesn't really make sense to say you "can ... make" this happen.
This commit is contained in:
commit
ef4f2d640e
1 changed files with 5 additions and 5 deletions
|
|
@ -52,12 +52,12 @@ mod uninit;
|
|||
/// original.
|
||||
///
|
||||
/// Differs from [`Copy`] in that [`Copy`] is implicit and an inexpensive bit-wise copy, while
|
||||
/// `Clone` 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.
|
||||
/// `Clone` is always explicit and may or may not be expensive. [`Copy`] has no methods, so you
|
||||
/// cannot change its behavior, but when implementing `Clone`, the `clone` method you provide
|
||||
/// may run arbitrary code.
|
||||
///
|
||||
/// Since `Clone` is more general than [`Copy`], you can automatically make anything
|
||||
/// [`Copy`] be `Clone` as well.
|
||||
/// Since `Clone` is a supertrait of [`Copy`], any type that implements `Copy` must also implement
|
||||
/// `Clone`.
|
||||
///
|
||||
/// ## Derivable
|
||||
///
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue