Unspecific error on Fn trait bounds

[jlogan03]

Code

pub trait MyFn: Fn() -> () {}

fn do_f(f: &dyn MyFn) {}

fn main() {
    let f = || {};
    do_f(&f);
}

Current output

Jamess-MacBook-Pro:benchground jlogan$ cargo build
   Compiling benchground v0.1.0 (/Users/jlogan/git/benchground/benchground)
error[E0277]: the trait bound `[closure@src/fn_bound_repro.rs:6:13: 6:15]: MyFn` is not satisfied
 --> src/fn_bound_repro.rs:7:10
  |
7 |     do_f(&f);
  |          ^^ the trait `MyFn` is not implemented for closure `[closure@src/fn_bound_repro.rs:6:13: 6:15]`
  |
  = note: required for the cast from `&[closure@src/fn_bound_repro.rs:6:13: 6:15]` to `&dyn MyFn<Output = ()>`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `benchground` (lib) due to previous error
Jamess-MacBook-Pro:benchground jlogan$

Desired output

Some explanation of what part doesn't match or how a person might implement their intent would be helpful

Rationale and extra context

No response

Other cases

The error emitted is nearly the same regardless of the types of arguments in the trait and in the closure, but when the arguments are references, the error also lists separate lifetimes for each input, which makes it look like lifetimes are the issue - but it seems that they're not, since the issue persists even with no relevant lifetimes involved

Anything else?

No response

[jlogan03]

I believe the pattern that should be suggested there is something like this, using function pointers instead of a reference to a closure:

pub type MyFn = fn() -> ();

fn do_f(f: MyFn) {}

fn main() {
    let f = || {};
    do_f(f);
}

[compiler-errors]

The issue here is that there is no automatic implementation for MyFn. One way to fix this is to provide a blanket implementation:

impl<F> MyFn for F where F: Fn() {}

I guess we could suggest a blanket implementation, but I'm somewhat skeptical of the value of that suggestion, since it heavily depends on what the user is trying to do with the trait (and the existence of other impls that the blanket impl would conflict with).

[compiler-errors]

I believe the pattern that should be suggested there is something like this, using function pointers instead of a reference to a closure

This would only work if the closure doesn't capture anything from its environment. If it does, then the closure is a distinct type that cannot be coerced to a function pointer, and you'll get errors saying something like:

note: closures can only be coerced to `fn` types if they do not capture any variables
 --> src/main.rs:7:29
  |
7 |     let f = || { println!("{capture}") };
  |                             ^^^^^^^ `capture` captured here

[jlogan03]

Hmm, good point. I might be wrong here as well, but I don't think there's a way to implement a trait on a specific closure, so the blanket impl would be the only way to make the exact usage from the original example work... but this could definitely subvert the intent of the trait itself.

I know diagnostics don't usually suggest multiple options and this would be pretty verbose, but maybe the suggestion could present both options (blanket impl or change trait to function pointer type alias) with some discussion of the tradeoff?

[compiler-errors]

I don't think it makes sense in general to turn a &dyn Trait argument (with a Fn supertrait) into a fn pointer argument. It may have fixed your specific example, but it's too specific to be worth suggesting -- it both requires the compiler to do a lot mechanically, and also imo leads the user astray from one of the main usages of closures (capturing).

I've added a note in #115741 that points out if a trait has no implementations, but it doesn't go the full way to suggesting how such a blanket impl would be written -- I fear that would be too "specific" for other cases.

[jlogan03]

Copy, makes sense. Thanks!