Cannot call implementations of the `Fn*` traits on references

[shepmaster]

Attempting to implement FnOnce for a reference to a struct or a trait object:

#![feature(fn_traits)]
#![feature(unboxed_closures)]

struct S;

fn repro_ref(thing: &S) {
    thing();
}

impl<'a> FnOnce<()> for &'a S {
    type Output = ();

    extern "rust-call" fn call_once(self, _arg: ()) -> () {}
}

fn main() {}

Produces the error:

error[E0618]: expected function, found `&S`
 --> src/main.rs:7:5
  |
7 |     thing();
  |     ^^^^^^^
  |
note: defined here
 --> src/main.rs:6:14
  |
6 | fn repro_ref(thing: &S) {
  |              ^^^^^

Interestingly, both of these alternatives work:

fn ok_ref_ref_arg(thing: &&S) {
    thing();
}

fn ok_ref_ref(thing: &S) {
    (&thing)();
}

cc #29625.

Originally from this Stack Overflow question.

[eddyb]

cc @nikomatsakis Sounds like the overloaded call derefs too eagerly? Or is missing autoref?

[earthengine]

I am the one that posted the relevant StackOverflow question. I found some more example:

trait T1 {
}

trait T2 {
}

impl<'a> T1 for &'a T2 {
}

struct S {
}

impl T2 for S {
}

fn main() {
    let t2:&T2 = &S {};
    let t1:&T1 = &t2; //This is OK
    let t3:&T1 = t2; //E0308: Expecting `T1`, found `T2`
}

Note the above does not require any features and behave the same in all channels. So, there has nothing to do with closures and Fn Traits. It is about implementing traits for a trait object reference type.

[earthengine]

In the simplified example, I tried to defense the current compiler behavior.

The statement let t3: &T1 = t2; says

take t2 (which is a trait object of type &T2) and bind it to a variable t3, which is a trait object reference to something implements T1.

t2 is a reference, but pointing to T2, it is NOT a reference to T1. As t2 is a variable, not an expression, the compiler is not able to introduce code to convert the variable unless some automatic conversion applies here. Unfortunately, the language does not allow using implementation of traits to do automatic conversion.

On the other hand, let t1: &T1 = &t2; says

calculate expression &t2 and bind the result to a variable t1, which is a trait object reference to something implements T1.

The difference here is we now have an expression, so it have to be calculated. The type checker will make sure the result is a reference to T1, and to do this the compiler have to search for the trait implementation for &T2.

So, although counter intuitive, but the current compiler behavior is not wrong. I think to achieve the designated usage, what we want to do is not implement a trait on top of a trait object, but to implement the conversion traits instead (already in my to-study list), so the compiler can apply the conversion automatically.

[nikomatsakis]

I'm not sure what's going wrong. Have to trace through it I guess. I added this bug as a blocker to stabilizing. Going to call it P-medium.

triage: P-medium

[alexreg]

Progress on this lately? :-)

[alexreg]

Are we in a good place to tackle this now that #45510 has been solved?

[elycruz]

One more example that works:

fn repro_ref(thing: impl FnOnce() -> ()) {
    thing();
}

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=b53ffaf9ecf6bc8f4856d93b8d491993

[eddyb]

@elycruz That's missing the reference though, this OTOH does error:

fn repro_ref(thing: &impl FnOnce()) {
    thing();
}

Interestingly, the error is different with a generic like that (it doesn't have to be impl FnOnce(), it could also be an F: FnOnce() named type parameter).

(Btw, your link is just to the playground, not to your example - you need to press the Share button and copy the first link from there)