Fn is apparently not implemented for fn

[kemurphy]

fn foo(x: u32) -> u32 { x }

fn main() {
    let x = foo.call((42,));
    println!("{}", x);
}

<anon>:4:17: 4:28 error: type `fn(u32) -> u32 {foo}` does not implement any method in scope named `call`
<anon>:4     let x = foo.call((42,));
                         ^~~~~~~~~~~
error: aborting due to previous error

http://is.gd/XTrYgZ

[nodakai]

As far as I know plain fns don't implement Fn etc. by design. How about wrapping fn as a closure?

#![feature(unboxed_closures)]

fn foo(x: u32) -> u32 { x }

fn main() {
    let cl = |&: x| foo(x);
    let x = cl.call((42,));
    println!("{}", x);
}

• http://is.gd/bQqLfY (playpen)

[sfackler]

Bare fns can be used in locations that an implementation of Fn is expected:

fn foo<F>(_: F) where F: Fn() {}

fn bar() {}

fn main() {
    foo(bar)
}

I'm not sure how it's implemented.

[nodakai]

@sfackler Oops, I misunderstood what this meant:

One (somewhat open) question is whether there will be additional traits that mirror fn types that might benefit from this more general sugar.

The new coercion rules state bare fns implement all of Fn, FnMut and FnOnce:

• https://github.com/rust-lang/rfcs/blob/master/text/0401-coercions.md#function-type-polymorphism

So, this is perhaps simply because .call() is still in an early stage of development:

• https://github.com/rust-lang/rfcs/blob/master/text/0439-cmp-ops-reform.md#closure-traits

[nikomatsakis]

This is caused by the fact that the method dispatch path is somewhat different from normal trait dispatch. Bah.

[bombless]

#![feature(unboxed_closures)]
fn foo(x: u32) -> u32 { x }

fn main() {
    let x = Fn::<(u32,),u32>::call(&foo, (42,));
    println!("{}", x);
}

You can do it this way for soon.
#16293 It is called UFCS and it causes internal compile error for now.

[alexcrichton]

This appears to have been fixed since being opened.