Copy not implemented on returned closures

[zakcutner]

I am exploring how the Copy trait is implicitly added to closures as in this RFC. As a simple example, let's say I create a function foo which takes a Copy closure.

fn foo(f: impl Fn(i32) + Copy) {
    f(10);
}

Although in this case f does not need to be Copy, this is just to simplify the example, let's pretend that it really does. Now I create a function bar which returns the same type of closure that foo accepts.

fn bar() -> impl Fn(i32) {
    |x: i32| {
        println!("{}", x);
    }
}

From my reading of the RFC, the returned closure should implicitly implement Copy. However, if I try to call foo with the result from bar, the compiler gives me an error because I do not explicitly implement Copy on the closure returned by bar.

foo(bar());
    ^^^^^ the trait `std::marker::Copy` is not implemented for `impl std::ops::Fn<(i32,)>`

Whilst I could change the signature of bar to return impl Fn(i32) + Copy let's assume that I do not have control over this function as it is defined in another crate. Interestingly, if I wrap the whole thing in another (and pointless!) closure, it works 👀

foo(|x: i32| bar()(x));

I have seen this exact pattern come up when using combinator libraries (nom for instance), and the second working solution is pretty frustrating as the outer closure has no purpose.

1. Is this the intended behaviour of the Rust compiler? Surely this is a bug that it can only infer Copy on local closures and not those returned by functions?

2. Is there something simple I'm missing; maybe I can write this in another way to avoid this issue? For this, please assume that I cannot edit foo or bar as this is based on real examples where combinators I use are defined by other crates.

Thank you! 😄

[zakcutner]

If you would like to try this out for yourself, I have created this example on the playground

[rodrimati1992]

You have to write -> impl Fn(i32) + Copy,otherwise the returned closure is allowed to not be Copy,and you wouldn't be able to use the fact that it's Copy outside the fn.
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=a88cce55fb8b6b2a12f653281aa56581

fn foo(f: impl Fn(i32) + Copy) {
    f(10);
}

fn bar() -> impl Fn(i32) + Copy {
    |x: i32| {
        println!("{}", x);
    }
}

fn main() {
    foo(bar());
}

[zakcutner]

Whilst I could change the signature of bar to return impl Fn(i32) + Copy let's assume that I do not have control over this (bar) function as it is defined in another crate.

@rodrimati1992 Thanks for your reply! I am aware of this however please see my question above for why I can't do this... I have encountered this exact problem! My issue is that the compiler seems able to infer implicit Copy when the closure is local, why doesn't it do the same for returned closures?

[rodrimati1992]

That's how impl Trait return types work,you can only use the traits that are part of their type.

[zakcutner]

That's how impl Trait return types work,you can only use the traits that are part of their type.

Right, but the Rust compiler can figure out the Copy implicitly when it's local... I appreciate that it doesn't currently support this (whether this is intended or a bug?), however this is a common problem when using combinators and the foo(|x: i32| bar()(x)) alternative in my question is a really annoying pattern! Surely there should be a better way to achieve this?

[Centril]

1. Is this the intended behaviour of the Rust compiler?

Yes, this is intended behavior. Only auto traits leak out from impl Trait and Copy is not such a trait.

[zakcutner]

Yes, this is intended behavior. Only auto traits leak out from impl Trait and Copy is not such a trait.

@Centril Okay, would there be a possible change to the compiler/language that could fix this? Or alternatively, is there another way that currently exists to achieve what I'm trying to do in a nicer way?

[Centril]

Possible? Yes. Desirable? Unlikely, as it would require special casing Copy. The very point of -> impl Trait is to hide unpromised internal details from the caller, and so exposing Copy implicitly, beyond being an ad-hoc special case, would also weaken such guarantees.

I'm not aware of other ways at this time.

[zakcutner]

@Centril Thanks, that's really helpful! I have a few questions about this...

1. Is Copy not already treated as a special case by the compiler in order for the original RFC to work or do I misunderstand?

2. To clarify, are you saying that the foo(|x: i32| bar()(x)) solution is currently the best one you are aware of?

[Centril]

1. Is Copy not already treated as a special case by the compiler in order for the original RFC to work or do I misunderstand?

That's the wrong RFC (you want the -> impl Trait one). :) The compiler treats Copy specially in some circumstances, but not here.

2. To clarify, are you saying that the foo(|x: i32| bar()(x)) solution is currently the best one you are aware of?

I don't know enough about your use case to say I'm afraid.

[zakcutner]

@Centril Okay, thanks I understand. For me, the solution of foo(|x: i32| bar()(x)) is unsatisfactory as, even if the compiler can optimise it away, the additional closure is pretty ugly and in larger examples could make the code kinda confusing.

Therefore, although there may not currently be an easy way to resolve this, since the underlying issue has not been solved, would it be possible to re-open it as a feature request / request for suggestions as others may have further ideas on how this can be improved? Alternatively, is this better suited to an RFC and/or is there additional information I can provide to help clarify where the problem occurs?