make Copy: Clone

[nikomatsakis]

It really makes sense for Clone to be a supertrait of Copy -- Copy is a refinement of Clone where memcpy suffices, basically. I've got a branch handling most of this, though it requires adding a lot of #[derive(Copy, Clone)] sort of things.

[nikomatsakis]

cc @aturon @alexcrichton

[nikomatsakis]

triage: P-backcompat-lang (1.0 beta)

[Gankra]

💖 ✨ ✨ ✨

[nikomatsakis]

@gankro I'm in the tedious process of adding clone impls to run-pass tests right now... woohoo...

[Gankra]

I'm sure this is what has been causing all the spurious buildbot failures.

[alexcrichton]

though it requires adding a lot of #[derive(Copy, Clone)] sort of things.

Does this mean that we have many Copy things which are not Clone today?

[aturon]

I'm very happy with this pragmatic way of resolving the Copy/Clone dichotomy.

[barosl]

Does this mean the types with Clone will be implicitly copied, when they were previously moved? Isn't this confusing to move semantics?

[tomjakubowski]

@barosl I don't think so, I think it just means that for a type to impl Copy it must also impl Clone.

[bombless]

Yeah I guess #[derive(Copy, Clone)] will keep as-is, while some #[derive(Copy)] will trigger error.

[Kimundi]

Sounds like a simple solution, I like it!

[nikomatsakis]

@alexcrichton

Does this mean that we have many Copy things which are not Clone today?

yes, yes, it does. Not so much in the libraries, I don't think, though there as well.

[nikomatsakis]

@gankro

I'm sure this is what has been causing all the spurious buildbot failures.

Um, what? (I have no idea what you mean...)

[nikomatsakis]

@alexcrichton see #23860

[ghost]

Does it make sense to consider how ToOwned fits into the picture here too? I know it's potentially unrelated but the current interaction between Clone and ToOwned when defining new data structures that hold Cow things is a bit awkward due to impl<T> ToOwned for T where T: Clone.

[bombless]

Does it make sense to consider how ToOwned fits into the picture here too?

I think now ToOwned automatically turn &T and &mut T into T (when T: Copy) and that makes sense.

[aturon]

@freebroccolo

Does it make sense to consider how ToOwned fits into the picture here too? I know it's potentially unrelated but the current interaction between Clone and ToOwned when defining new data structures that hold Cow things is a bit awkward due to impl<T> ToOwned for T where T: Clone.

I've been vaguely uneasy about the relationship between ToOwned and Clone for a while, but I hadn't quite realized that implication of the blanket impl.

Do you have any thoughts on the direction here? I could imagine removing the blanket impl of ToOwned, although I'm not sure exactly what the fallout would be.

[Gankra]

Niko: just goofin' around! :)