async fn lifetime eliding satisfies HRTB where explicit does not

[Wolvereness]

In this code, two generators are defined. Their definitions should be equivalent. The async-fn variant where lifetimes are elided works fine, but the variant where the lifetimes are defined explicitly with an impl-trait return fails to compile against the HRTB.

Playground with more definitions to actually build.

trait AsyncFnOnce<Arg> {}
impl<F, A, B, R: Future> AsyncFnOnce<(A, B, )> for F
    where
        F: FnOnce(A, B) -> R,
{}

pub unsafe trait RemitWithLifetime<T, X> {}
unsafe impl<T, X, F> RemitWithLifetime<T, (X, )> for F
    where
        F: for<'a> AsyncFnOnce<(X, Remit<'a, T>, )>,
{}

impl<T, P> Generator<T, P> {
    pub fn parameterized<'s, G, X>(
        self: Pin<&'s mut Self>,
        _gen: G,
        _parameter: X,
    ) -> GeneratorIterator<'s, T, P>
        where
            // insures fn is not implemented only for 'static
            G: RemitWithLifetime<T, (X,)>,
            // insures P is properly defined, even if it actually has a lifetime
            G: FnOnce(X, Remit<'static, T>) -> P,
    {
        unimplemented!();
    }
}

use std::pin::pin;
fn only_build() {
    let data = String::from("hi");

    /// Implicit elision works
    async fn gen_implicit(data: &str, remit: Remit<'_, usize>) {
        remit.value(data.len()).await;
        remit.value(data.len()).await;
    }
    for item in pin!(Generator::new()).parameterized(gen_implicit, &data) {
        dbg!(item);
    }
    
    /// Does not work, as explicit lifetime definitions fail HRTB.
    fn gen_explicit<'a: 'c, 'b: 'c, 'c>(data: &'a str, remit: Remit<'b, usize>) -> impl std::future::Future<Output=()> + 'c {
        async move {
            remit.value(data.len()).await;
            remit.value(data.len()).await;
        }
    }
    for item in pin!(Generator::new()).parameterized(gen_explicit, &data) {
        dbg!(item);
    }
}

Both gen_implicit and gen_explicit should have been able to be used successfully.

Instead, there is a compiler error:

error: implementation of `FnOnce` is not general enough
  --> src/lib.rs:49:17
   |
49 |     for item in pin!(Generator::new()).parameterized(gen_explicit, &data) {
   |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ implementation of `FnOnce` is not general enough
   |
   = note: `fn(&str, Remit<'2, usize>) -> impl Future<Output = ()> + '_ {gen_explicit::<'_, '2, '_>}` must implement `FnOnce<(&str, Remit<'1, usize>)>`, for any lifetime `'1`...
   = note: ...but it actually implements `FnOnce<(&str, Remit<'2, usize>)>`, for some specific lifetime `'2`

[compiler-errors]

This is because of the lifetime-outlives bounds in the signature of gen_explicit. Adding : 'c to 'a and 'b make both of those early-bound lifetimes, which means the signature of gen_explicit is not for<'a, 'b> fn(&'a str, Remit<'b, usize>) -> ... anymore.

[compiler-errors]

You can use the "captures" trick/hack to fix this, though, and write an impl Future that captures both 'a and 'b, something like: https://www.diffchecker.com/mh96zLFq/

[Wolvereness]

This is because of the lifetime-outlives bounds in the signature of gen_explicit. Adding : 'c to 'a and 'b make both of those early-bound lifetimes, which means the signature of gen_explicit is not for<'a, 'b> fn(&'a str, Remit<'b, usize>) -> ... anymore.

It would make sense to support multiple bounds (+ 'a + 'b) in that sense.

You can use the "captures" trick/hack to fix this, though, and write an impl Future that captures both 'a and 'b, something like: https://www.diffchecker.com/mh96zLFq/

This report is about whether or not you should need to do that, rather than simply making it work. Hacks aren't ergonomic.

[compiler-errors]

It would make sense to support multiple bounds (+ 'a + 'b) in that sense.

+ 'a + 'b means that the opaque type must outlive both 'a and 'b independently, since each bound is verified independently. Unfortunately, we're probably not going to change the meaning of this.

This report is about whether or not you should need to do that, rather than simply making it work. Hacks aren't ergonomic.

Currently, yeah, you need to do that. We're working on changing the semantics of lifetime captures in return-position impl trait, but it's a pretty involved discussion. See these meeting notes for a start.

[Wolvereness]

It would make sense to support multiple bounds (+ 'a + 'b) in that sense.

+ 'a + 'b means that the opaque type must outlive both 'a and 'b independently, since each bound is verified independently. Unfortunately, we're probably not going to change the meaning of this.

Putting a lifetime on an opaque type in the return position (sorry, I guess I didn't clarify?) means that it cannot/must-not outlive the specified lifetime (because it captures said value). In this context, fn gen<'a, 'b>(...) -> Future + 'a + 'b or the suggestion of fn gen<'a, 'b>(...) -> Future + Capture<(&'a (), &'b ())> should imply the same as fn gen<'a: 'c, 'b: 'c, 'c>(...) -> Future + 'c. The surrounding semantics (or lack thereof) of why it doesn't do that are the problem here. I do understand that it probably won't be fixed that way.

This report is about whether or not you should need to do that, rather than simply making it work. Hacks aren't ergonomic.

Currently, yeah, you need to do that. We're working on changing the semantics of lifetime captures in return-position impl trait, but it's a pretty involved discussion. See these meeting notes for a start.

Is there another tracking issue for the underlying problems associated with not having those proper semantics? I could/would close this issue as a duplicate, but I couldn't find one and don't see any linked.

[traviscross]

@rustbot labels +AsyncAwait-Triaged

We discussed this in a WG-async meeting and are deferring to the analysis by @compiler-errors above.