- Feature Name: N/A
- Start Date: 01 March, 2016
- RFC PR: rust-lang/rfcs#1521
- Rust Issue: rust-lang/rust#33416
Summary
With specialization on the way, we need to talk about the semantics of <T as Clone>::clone() where T: Copy
.
It's generally been an unspoken rule of Rust that a clone
of a Copy
type is equivalentmemcpy
of that type; however, that fact is not documentedClone
trait, just like the fact that T: Eq
should implementa == b == c == a
rules.
Motivation
Currently, Vec::clone()
is implementedVec
, and then cloning all of the elementsmemcpy
the values from the old Vec
to the new Vec
in the case of T: Copy
. However, if we don't specify
It's always been the intention that Clone::clone == ptr::read for T: Copy
; see issue #23790: "It really makes sense for Clone
to be a supertrait of Copy
-- Copy
is a refinement of Clone
where memcpy
suffices, basically." This idea was also implicit
Detailed design設計(する)
Specify<T as Clone>::clone(t)
shall be equivalentptr::read(t)
where T: Copy, t: &T
. An implementationClone
is not an unsafe trait
.
Also add something like the following sentence to the documentationClone
trait:
"If T: Copy
, x: T
, and y: &T
, then let x = y.clone();
is equivalentlet x = *y;
. Manual
Drawbacks
This is a breaking change, technically, although it breaks code that was malformed in the first place.
Alternatives
The alternativeclone_from_slice
.
Unresolved questions
What the exact wording should be.