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:
Jacob Pratt 2025-12-24 02:52:59 -05:00 committed by GitHub
commit ef4f2d640e
No known key found for this signature in database
GPG key ID: B5690EEEBB952194

View file

@ -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
///