Unboxed closure types are implicitly copyable

[nikomatsakis]

Unboxed closure types should be consistent with structs and hence should not by implicitly copyable. They were essentially forgotten by the opt-in copy work.

[nikomatsakis]

Nominating for 1.0 p-backcompat-lang.

[nikomatsakis]

Example test:

fn do_it(x: &int) { }

fn main() {
    let f = move|:| ();
    f();
    f();
}

This test passes but should not, I think.

[japaric]

What happens if you actually want the unboxed closure to be copyable? How do you opt-in? Following your example, how do I say: "I want f/|| {} (which has an anonymous type) to be copyable".

[bluss]

With clonable iterators in mind (PR #19837), I wonder if unboxed closures can impl Clone automatically?

[ghost]

Like @japaric, I'm also interested in having copyable closures somehow without having to resort to low-level magic.

[ftxqxd]

I think that closures should implement Copy automatically. There are plenty of semi-built-in compound types today that are implicitly copyable ([Copyable, ..n], (Copyable1, Copyable2, ...)), so it’s actually more consistent for unboxed closures to behave the same, because unboxed closures are basically just (fn(args) -> ret, upvar1, upvar2).

And if there’s literally no way to get unboxed closures to opt in to Copy, then I don’t think it’s a good idea to disallow that.

[alexcrichton]

Closed by #19889