`AsyncFnOnce(…)` and `FnOnce<(…), Output : Future>` are not equivalent

[danielhenrymantilla]

The following two calls fail:

fn fut_closure<F: FnOnce() -> Fut, Fut : Future<Output = ()>>(f: F) {
    async_closure(f); // error, `F` is not `AsyncFnOnce`.
}

fn async_closure<F: AsyncFnOnce()>(f: F) {
    fut_closure(f); // error, `F` is not `FnOnce`.
}

even though future-outputting fns (e.g., fn … -> impl FutureOrSubtraitThereof), async fns, and async closure literals (async [move] |…| {…}) implement both flavors of the {Async,}FnOnce traits.

Why is this a problem

Rust 1.85.0 is too recent to be an acceptable MSRV for a bunch of projects, so the F: AsyncFnOnce version may not be usable in certain libraries.

This, in turn, entails that "middleware" functions either use the same matching bound as the library used _{^{(unless they perform eta-expansion of the closure to get back the double-impl that the compiler provides to async closures literals)}}:

fn middleware1(f: impl AsyncFnOnce()) {
    ::lib::api(f); // Error
}

fn middleware2<Fut : Future<Output = ()>>(f: impl FnOnce() -> Fut) {
    ::lib::api(f); // OK, but now `api` can't switch to `AsyncFnOnce` without breaking us.
} // (and also, neither can we!)

And because they might do the former, it also means that in the future, once the MSRV gets to become high enough, the library author cannot replace the FnOnce bound with AsyncFnOnce without causing breakage¹.

Suggested Solution

Caution

EDIT: this does not work because of the &Fn => FnOnce blanket impl: if we also had the suggested AsyncFnOnce => FnOnce blanket impl as well, then there would be an overlap for impl &Fn + AsyncFnOnce types.

1. Add : FnOnce<Args, Output = Self::CallOnceFuture> as a super-trait of AsyncFnOnce,
2. blanket-implement AsyncFnOnce for all impl FnOnce<Args, Output : Future> types,
3. adjust the compiler-code to implement FnOnce only since AsyncFnOnce is now covered by the blanket impl.

This means that library authors can keep using FnOnce for lower-than-1.85.0 MSRV support, while hoping to migrate to the cleaner and nicer AsyncFnOnce eventually, e.g._, 1.88.0? 🤞), without requiring a major bump.

• unless there are some compiler-specific implementation-related complications with doing this? cc @compiler-errors 🙏

Aside: this will not be possible for the AsyncFn{,Mut} traits

Since they're actually special in how they're actually Future-outputting LendingFn{,Mut}s rather than bare Future-outputting Fn{,Mut}s. But this fact should not affect FnOnce.

@rustbot label: +A-async-closures

Footnotes

1. there is also the question of explicit generic params vs. turbofish, but using a helper definition like in https://docs.rs/async-fn-traits does allow one to avoid exposing a turbofishable Fut in Rust 1.85.0, so this is not a true/genuine issue (just something to be mindful of). ↩

[moxian]

@rustbot label: +C-discussion +T-types +T-lang

[compiler-errors]

I noted this in the async closure stabilization report:

For now, this only works currently for concrete callable types -- for example, a argument-position impl trait like impl Fn() -> impl Future<Output = ()> does not implement AsyncFn(), due to the fact that a AsyncFn-if-Fn blanket impl does not exist in reality. This may be relaxed in the future. Users can work around this by wrapping their type in an async closure and calling it. I expect this to not matter much in practice, as users are encouraged to write AsyncFn bounds directly.

Though I do agree that this can be fixed for AsyncFnOnce/FnOnce by simply adding the supertrait. I'll probably experiment w/ that soon.

[compiler-errors]

Actually, I don't believe this is fixable right now. Just because a type implements AsyncFnOnce actually doesn't imply that it implements FnOnce!

#![feature(impl_trait_in_bindings)]
// ^^^ Just for demonstrative purposes ^^^

fn foo() {
    let mut lend = String::new();
    let x = async move || {
        println!("{lend:?}");
    };

    // Proof that `x` is lending, i.e. doesn't impl `Fn`
    //let _: impl Fn() -> _ = x; //~ ERROR

    // Proof that `x` implements `AsyncFnOnce`
    let _: impl AsyncFnOnce() = x;

    // Proof that `x` implements `FnOnce`
    let _: impl FnOnce() -> _ = x;

    // Proof that `&x` implements `AsyncFnOnce`
    let _: impl AsyncFnOnce() = &x;

    // Proof that `&x` does NOT implement `FnOnce`
    let _: impl FnOnce() -> _ = &x; //~ ERROR
}

Specifically, &{async closure} doesn't always implement FnOnce because the blanket implementation¹ requires that {async closure}: Fn, which is not true if the closure is lending.

To fix this the other way around, we would need to restrict the blanket implementation² impl<F> AsyncFnOnce for &F where F: AsyncFn to be far less useful (i.e. never work for &{async closure} that is lending).

This may be fixable in the future if we were to introduce a first class LendingFn/LendingFnMut traits and adjust the blanket impl for impl<F> FnOnce for &F where F: Fn to be impl<F> FnOnce for &F where F: LendingFn. That may come with its own problems though.

Footnotes

1. https://doc.rust-lang.org/std/ops/trait.FnOnce.html#impl-FnOnce%3CA%3E-for-%26F ↩

2. https://doc.rust-lang.org/std/ops/trait.AsyncFnOnce.html#impl-AsyncFnOnce%3CA%3E-for-%26F ↩

[danielhenrymantilla]

Ah yeah true, once we reach diamond blanket impl hell, at worst it's a complete deal breaker, or at best the complexity just skyrockets; and even in the latter case the benefit here would not be worth it.

Thanks for having come back to this and for the detailed explanation 🙏