Rules around call resolution on `fn_traits` are confusing

[Kolsky]

I tried this code:

#![feature(fn_traits, unboxed_closures)]

pub struct Foo<F>(F); // a simple newtype over closure object, nothing more

impl<F: FnOnce(A) -> B, A, B> FnOnce<(A,)> for Foo<F> {
    type Output = B;

    extern "rust-call" fn call_once(self, (a,): (A,)) -> B {
        (self.0)(a)
    }
}

impl<F: FnMut(A) -> B, A, B> FnMut<(A,)> for Foo<F> {
    extern "rust-call" fn call_mut(&mut self, (a,): (A,)) -> B {
        (&mut self.0)(a)
    }
}

impl<F: Fn(A) -> B, A, B> Fn<(A,)> for Foo<F> {
    extern "rust-call" fn call(&self, (a,): (A,)) -> B {
        (&self.0)(a)
    }
}

fn main() {
    let mut s = String::new();
    
    // This works
    {
        let mut closure = |()| s.push_str("");
        (move |x| closure(x))(());
    }
    
    // This doesn't!
    {
        let closure = |()| s.push_str("");
        (Foo(closure))(());
    }
}

(playground)

I expected to see this happen: FnMut gets picked up as the next candidate fitting for closure call, code compiles succesfully.

Instead, this happened: the closest candidate in method resolution should be Self, if anything, but, evidently, &Self is preferred instead. It would be justifiable for closures specifically if the code could be compiled. It doesn't seem to align with anything known so far about either closures or method call expressions. Removing Fn impl makes the code compile successfully, but it shouldn't be considered at all due to unsatisfied F: Fn bound.

Meta

rustc version: 1.76.0 nightly

Main tracking issue: #29625

[compiler-errors]

The only reason this works for closures is because we defer closure call resolution to the end of type checking, and we don't apply autoref or autoderef on closure calls until we've determined the closure's captures and kind.

It doesn't seem to align with anything known so far about either closures or method call expressions.

Given that the Fn traits are currently unstable -- and not really in shape for friendly user-facing usage yet, to be honest -- we don't really guarantee anything about their behavior except for what you can witness on stable code.

If you do want to understand how these things work under the hood, my best recommendation is to just read the compiler code. You can look for CallStep::DeferredClosure and deferred_call_resolutions to find some of the machinery that allows closures to select the right Fn-family trait without yet knowing what it implements.

[ijackson]

I don't think it's all that bad :-). It's true that there's some magic about automatic selection of the right trait for closures. But. in many realistic scenarios, you're passing the implementor of the Fn traits to some other function that knows what it needs

Eg, this works:

fn call_fnmut<A>(mut cl: impl FnMut(A), a: A) {
    cl(a);
}
    {
        let mut closure = |()| s.push_str("");
        call_fnmut(move |x| closure(x), ());
    }
    {
        let closure = |()| s.push_str("");
        call_fnmut(Foo(closure), ());
    }

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=40754397ad9fce96cbf1c52528e1231d

Likewise if the newtype knows which fn traits it implements. https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=3058e46a99343243aaa8eef01b3351fd

The problems seem to come if you want the closure trait selection (type inference) to pass through generics on your newtype. Or to put it another way, the generics on the newtype act as a barrier for fn trait selection - an inference barrier between the definition of an actual closure, and place where the newtype is called.

(I think this is no more than a "Rust can't compile your program yet" problem, assuming you don't mind that Rust sometimes picks Fn when FnMut or FnOnce would have been possible too.)