functions implement Copy but not Clone

[fuchsnj]

This compiles

fn func(){}

fn main(){
    run(func);
    run(func);
}

fn run<T>(f: T)
where T: Fn() + Copy{
    f();
}

but this does not (playground)

fn func(){}

fn main(){
    run(func);
    run(func);
}

fn run<T>(f: T)
where T: Fn() + Clone{
    f();
}

The only difference is the bounds on T. The Copy trait requires that the Clone trait is also implemented, so I believe both of these should compile.

[jonas-schievink]

Even worse, because Copy usually implies Clone, this ICE's:

fn c<T: Copy>(t: T) -> (T, T) { (t.clone(), t) }

fn f() {}

fn main() {
    c(0);
    c(f);
}

<anon>:1:34: 1:43 error: internal compiler error: Encountered error `Unimplemented` selecting `Binder(<fn() {f} as core::clone::Clone>)` during trans
<anon>:1 fn c<T: Copy>(t: T) -> (T, T) { (t.clone(), t) }
                                          ^~~~~~~~~

This (including the ICE) was already reported in #24000, so this looks like a duplicate

[alexcrichton]

Nominating as this seems relatively serious, but the failure mode is just an ICE then it doesn't seem super super pressing.

[arielb1]

@nikomatsakis: should we make Clone a lang-item? I think it being a supertrait of Copy forces our hand.

[eefriedman]

We could just add something like the following to the libcore, I think:

impl<R> Clone for fn() -> R {
    fn clone(&self) -> Self { self }
}
impl<R, A1> Clone for fn(A1) -> R {
    fn clone(&self) -> Self { self }
}
impl<R, A1, A2> Clone for fn(A1, A2) -> R {
    fn clone(&self) -> Self { self }
}
impl<R, A1, A2, A3> Clone for fn(A1, A2, A3) -> R {
    fn clone(&self) -> Self { self }
}

We do exactly the same thing for arrays.

[eefriedman]

Err, nevermind, that doesn't really do the right thing: that only works for function pointers, not function definitions.

[nagisa]

impl<T: Copy> Clone for T?

I’m pretty sure this cannot be done backwards compatibly because such impl would conflict with all the explicit impl Clones, but still had to mention it 😊

[huonw]

@nagisa it should be fine with specialisation.

[arielb1]

@huonw

It would be fine with lattice impls. Which is a different feature from specialization. Actually, even that wouldn't be backwards-compatible, given that you would need to provide the meet impls (e.g. impl<T: Copy> Clone for Option<T>) or to have some sort of priority mechanism.

[huonw]

I don't understand what you mean, allowing more specialised impls (i.e. this) is exactly what specialisation is. Anyway nitpicking the exact terminology probably doesn't matter so much here...

[arielb1]

@huonw

@aturon's specialization RFC - rust-lang/rfcs#1210 - does not allow for overlapping impls in any case. There are also proposals for "lattice impls", which allow overlapping impls as long as there is a meet between every 2 impls. This is not part of the RFC.

[huonw]

Ah, I was speaking more abstractly, but in fact, @aturon has realised a modification to the RFC that allows cases like this, just hasn't had time to publish.

[nikomatsakis]

On Fri, Sep 04, 2015 at 01:33:13PM -0700, arielb1 wrote:

@nikomatsakis: should we make Clone a lang-item? I think it being a supertrait of Copy forces our hand.

Possibly. My preferred strategy here would be to leverage
specialization, such that we have a blanket impl of Clone for all T: Copy. I know that some variants of specialization cannot accommodate
this, though.

[arielb1]

@nikomatsakis

Variants which include all these proposed in the RFC.