#[derive(Clone)] should rely on Copy when possible

[SimonSapin]

When a type that is also Copy has #[derive(Clone)], the derived implementation should be:

    fn clone(&self) -> Self { *self }

From #27750 (comment)

As the example in #27750 (comment) shows, even when a composite type like Composite is Copy, its clone implementation may be less efficient than its Copy impl, due to copying fields individually instead of as a block.

Maybe being Copy is hard to determine exactly by the time #[derive(Clone)] needs to do its thing, but at least this could happen when both traits are in the same derive attribute? #[derive(Copy, Clone)]

[bluss]

A more specific example https://play.rust-lang.org/?gist=ef17b9c31e01be5f65c2&version=nightly where clone_composite is a loop and copy_composite turns into memcpy.

[sfackler]

We currently just desugar #[derive(Clone, Copy)] to #[derive_Clone] #[derive_Copy] and expand those separately, but it could special case the Clone and Copy combo.

[alexcrichton]

I would be quite ok specializing #[derive(Clone, Copy)], much else beyond that does seem unfortunately quite difficult :(

[SimonSapin]

It’s a start, and it may even be the common case.

[retep998]

I've had to use a macro to define all my structs in winapi just so I can get that efficient Copy-based Clone impl to improve compile times.

[durka]

Okay, so thinking aloud about this idea of special-casing #[derive(Copy, Clone)] as #[derive_CopyClone] and making that More Magic (tm).

From the code

#[derive(Copy, Clone)]
struct S<T>(T);

fn main() { }

you get (cleaned up)

struct S<T>(T);

impl <T: Clone> Clone for S<T> {
    fn clone(&self) -> S<T> {
        match *self {
            S(ref x) => S(Clone::clone(&*x)),
        }
    }
}

impl <T: Copy> Copy for S<T> { }

fn main() { }

Now instead of the above Clone impl we would like there to be

impl<T: Clone + Copy> Clone for S<T> {
    fn clone(&self) -> S<T> {
        *self
    }
}

but now S<T>: !Clone where T: Clone + !Copy (please forgive the horrible abuse of notation). Is it possible to do this in a backwards-compatible way? Maybe it can done only for types with no generic parameters?

[durka]

Playpen illustrating the above concern.

[bluss]

I think you would need specialization to supply both the where T: Clone and the where T: Copy implementations, the latter is more specific, so it should work out.

[durka]

So we'll revisit this after specialization lands?

[bluss]

You can do it well already for the case without type parameters

[durka]

Agreed.