RFC: Implement Clone on |A|: 'static -> R &'static fn()`

[bluss]

Some closures are shallow-clonable and should implement .clone().

One example is a &'static fn(A) -> R autoborrowed from an extern fn. If it's clonable then that could make an iterator adaptor like MapIterator clonable in some cases.

[catamorphism]

I think this is a change requiring an RFC.

Nominating so we can discuss it in triage.

[nikomatsakis]

Seems like a fine thing to do. We'll need a couple of impls for differing numbers of arguments.

[brson]

Good newbie bug.

[pnkfelix]

assigned to P-low to reflect that its not a big deal for 1.0 though.

[pnkfelix]

I just encountered a case where I think I want this.

The details, for those interested: I'm trying to set up a condition-like system, but where the exception responses are carried in objects rather than derived from the dynamic scope. I also want to be able to have child object initially set up its exception handler as a copy of the exception handler of the parent. I'm pretty sure the "obvious thing" is to use objects instead of closures here, since the objects could obviously implement clone, but it would be nice to inter-operate with functions, even if only ones that can be &'static borrowed.

[pnkfelix]

Ah wait, we also support clone on other kinds of fn, as added by PR #8109.

(But also issue #10501 might be a problem.)

[nikomatsakis]

So, there is some confusion between the spellings of various types -- what was &'static fn is now better written ||:'static (modulo issue #10553). By which I mean: a closure with a static bound is basically the same as a bare function. Anyway, I think the approach I laid out in #10501 subsumes this particular bug and is necessary for these kinds of clones to really work.

[erickt]

Edited the title to match the current syntax for closures. I believe this is an example test case if this were implemented.

fn foo() { println!("hi"); }

fn bar(x: ||: 'static) {
    (x)();
    let y = x.clone();
    (y)();
}

fn main() {
    bar(foo);
}

[nikomatsakis]

I think we ought to just close this issue. It'd require an RFC and would interact with plans for "unboxed closures" (#8622).