Make Clone a lang-item and implement it for closures whose members are all Clone

[arielb1]

moved from rust-lang/rust#23501

[withoutboats]

Could this be implemented using default impls of Clone and Copy? I know that would be a pretty serious breaking change, because there could be types that are only sound because they don't implement Clone. But in principle, wouldn't closures be Clone if their environment is Clone if that were the case (or do default impls not apply to closures)?

[jonas-schievink]

This is also needed to fix rust-lang/rust#28229

[mitchmindtree]

Just thought I'd 👍 this and mention a couple use-cases I come across quite frequently:

• Iterator ergonomics - being able to clone Iterators with some F: Fn + Clone field
• real-time thread synchronisation - being able to clone a F: Fn(&mut State) + Clone and send it to multiple real-time threads across via channels without requiring Arc

[ubsan]

Not just closures. Functions and arrays would be great as well.

[J-F-Liu]

Meet this same issue, here is an example:

#[derive(Debug)]
struct Take(String);

fn make<F>(func: F) -> Box<Fn(&str) -> Take>
    where F: FnOnce(String) -> Take + Copy + 'static
{
     Box::new(move |s| {
         func(s.to_string())
     })
}

fn main() {
    let m = make(|s|Take(s));
    println!("{:?}", m("abc"));
}

should compile.

[russellmcc]

I've started hitting this a lot, mostly in the "iterator ergonomics" that @mitchmindtree mentioned. I'm not sure why Clone needs to be a lang item (maybe there's something I'm missing), but having appropriate closures implement Clone sure would be convenient.

[cramertj]

Since Clone was made a lang item in rust-lang/rust#43690, I've written this up as #2132.

[scottmcm]

Since the RFC was accepted, closing in favour of the tracking issue rust-lang/rust#44490