I wanted to draw people’s attention to PR 23860 that makes Copy a subtrait of Clone (as originally proposed in issue 23790). This codifies the original intention that Copy is a refinement of Clone: that is, Copy indicates a type that can be cloned just by using a simple memcpy. In fact, making this change revealed many bugs in the standard library where types implemented only Copy and not Clone, which would have prevented those types from being used in generic APIs based on Clone. Another nice benefit of this is that it permits generic APIs to begin as T: Copy but later migrate to T: Clone if it is determined that the additional genericity outweights the potential performance hazard (this could be useful as a compromise for RFC 839, for example).
The primary downside of this change is that it requires modifying #[deriving(Copy)] to #[deriving(Copy, Clone)]; however, there are plans to modify deriving so that #[deriving(Copy)] implies an impl of Clone as well. Because that is a somewhat controversial decision, the idea was to propose that change separately.
Ideally, PR 23860 would go through the RFC process, but it’s a breaking change that really ought to happen before beta, and there’s just not time left. Fortunately, this change is merely codifying the expected relationship between the two traits more formally. But I still wanted to alert everyone to the change and get your opinion. Please feel free to comment here or on the PR. Thanks.
assuming it doesn’t cause any noticeable binary bloat. I can’t see any reason to impl Copy but not Clone. Although, you might want to revisit this if we ever get specialization/default impls: