Provide wrappers over Box<Fn>

[bombless]

Something like this:

#![feature(unboxed_closures, box_syntax)]
#![allow(unstable)]
struct Proxy<'a, Args, Ret> {
    closure: Box<Fn<Args, Ret> + 'a>
}
impl<'a, Args, Ret> Fn<Args, Ret> for Proxy<'a, Args, Ret> {
    extern "rust-call" fn call(&self, args: Args)->Ret {
        self.closure.call(args)
    }
}
impl<'a, Args, Ret> Proxy<'a, Args, Ret> {
    fn new<F: Fn<Args, Ret> + 'a>(closure: F)->Proxy<'a, Args, Ret> {
        Proxy { closure: box closure }
    }
}
fn main(){
    let celebrate = Proxy::new(|&: num: i64| {
        println!("Feels great to implement C++ std::function in {} lines.", num)
    });
    let lucy_number = Proxy::new(|&: num: i64| {
        println!("My lucky number is {}", num)
    });
    let func = if std::rand::random() { celebrate } else { lucy_number };
    func(25)
}

Or is it part of the plan? :p

[reem]

What's the benefit of the Proxy type over just using an Fn trait object directly?

[bombless]

A proxy is the same type while arguments type and return type are the same, thus makes it possible to write a if while both arms are closures.
Other than if, match arms can benefit from it, too.

[reem]

@bombless You can do the same thing by using regular trait objects, like so:

#![feature(box_syntax)]
#![allow(unstable)]
fn main(){
    let celebrate: Box<Fn(i64)> = box |&: num: i64| {
        println!("Feels great to implement C++ std::function in {} lines.", num)
    };
    let lucky_number: Box<Fn(i64)> = box |&: num: i64| {
        println!("My lucky number is {}", num)
    };
    let func = if std::rand::random() { celebrate } else { lucky_number };
    func(25)
}

You can even avoid the type annotations in a lot of cases.

[bombless]

@reem For my experience, annotations cannot be avoided in most cases.
And you are right, I usually do things in your way. I just think offering standard proxy will make it easier to write such code.
BTW it seems that we will have bare trait one day and this will no longer be a problem ( being able to return a bare trait from a function ).

[Gankra]

Seems like this bug just amounts to "closures are unergonomic", then?

[reem]

"conversion to trait objects is verbose and unergonomic" probably, which I have definitely experienced.

[bombless]

@gankro We can call it a feature, and I think the issue is the lack of relative facilities.

[bombless]

@reem Yeah maybe things will change once type inference is improved.
Is there a chance that boxing will be able to be done automatically according to type inference? If so then things can even become better.

[bombless]

#18875
If I understand correctly the Proxy code will not compile at the next nightly build of rustc, sad story.

[bombless]

nikomatsakis@152d623#diff-0
My bad, it's just behind an unboxed_closures feature gate, as always.

[sellibitze]

It seems the proxy type thingy serves no purpose. Sometimes, a function is all you need:

#![feature(unboxed_closures, box_syntax)]
#![allow(unstable)]

fn anyfunc<'a, Args, Ret, F>(closure: F) -> Box<Fn<Args, Ret> + 'a>
where F: Fn<Args, Ret> + 'a {
    box closure
}

fn main(){
    let celebrate = anyfunc(|&: num: i64| {
        println!("Feels great to implement C++ std::function in {} lines.", num)
    });
    let lucy_number = anyfunc(|&: num: i64| {
        println!("My lucky number is {}", num)
    });
    let func = if std::rand::random() { celebrate } else { lucy_number };
    func(25)
}

It's actually similar to what you would do in C++: write a function template à la make_shared etc. But I'm not sure if this is important enough to include it into the standard library.

[alexcrichton]

I agree with @reem, @gankro, and @sellibitze in that this may just be an issue of ergonomics as boxed trait objects/closures sound like they do what you already want. Could you open a new issue more focused on the ergonomics of boxed closures if you're concerned? Thanks!