Tracking Issue for RFC 3216: "Allow using `for<'a>` syntax when declaring closures"

[pnkfelix]

View all comments

This is a tracking issue for the RFC "Allow using for<'a> syntax when declaring closures" (rust-lang/rfcs#3216).
The feature gate for the issue is #![feature(closure_lifetime_binder)].

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Implement the RFC - implemented in Implement for<> lifetime binder for closures #98705
• Adjust documentation (see instructions on rustc-dev-guide)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

How does the explicit lifetime binder deal interact with elided lifetimes. The addition of higher-kinded inference variables (rust-lang/types-team#131) may change the preferred design here.

Implementation history

• Initial implementation in Implement for<> lifetime binder for closures #98705

[WaffleLapkin]

I'd like to work on implementing this 👀

@rustbot claim

[fmease]

The implementation section needs to be updated to mention #98705.

[fakedrake]

I bumped on this issue and I would like to share some code that maybe someone knowledgeable could comment on whether we are likely to get the features demonstrated or similar (in summary it's getting for<> for async closures):

#![feature(closure_lifetime_binder)]
#![feature(trait_alias)]

use core::future::Ready;
use core::future::ready;
use core::future::Future;

// Don't read too much into the implementation of `S`
struct S<'a>(&'a ());

trait AsyncF<'a, F> = Fn(S<'a>) -> F where F: Future<Output = S<'a>>;
async fn asyncF<F>(f: impl for<'a> AsyncF<'a, F>) {
    let a = ();
    f(S(&a)).await;
}

fn main() {
    // We can't seem to do this because for<> does not seem to extend to the
    // argument.
    asyncF(for<'a> |x: S<'a>| -> Ready<S<'a>> {ready(x)});

    
    // Ideally we would like this to do anything useful with for<> and async.
    // asyncF(for<'a> async move |x: &'a ()| -> &'a () {ready(x)});
}

playground

[WaffleLapkin]

@fakedrake I think your AsyncF/asyncF are wrong. You are using a single F type, that is supposed to implement for<'a> Future<Output = S<'a>>, where in reality you have a for<'a> F<'a>: Future<Output = S<'a>> type.

If you change the AsyncF trait to be something like the following:

trait AsyncF<'a, Input>: Fn(Input) -> Self::Future {
    type Future: Future<Output = Self::Out>;
    
    type Out;
}

impl<'a, F, Fut, In> AsyncF<'a, In> for F
where
    F: Fn(In) -> Fut,
    Fut: Future,
{
    type Future = Fut;
    type Out = Fut::Output;
}

Then your example works. Though I want to warn you that such traits are a pain to work with and especially extend.

---

As for for<'a> async move |x: &'a ()| -> &'a () kind of thing, I think it generally desired, but was ruled out of the scope of the RFC. So, if we'll ever add it, it would first need its own RFC.

It appears that async closures are currently in a very rough shape (eg) so a good place to start would probably be to fix/complete the implementation of async closures first.

[fakedrake]

Thank you very much. I have seen people vaguely complaining about the primitive state of async closures but besides this niche case I have found that they have worked pretty well. Is there an issue tracking the problems with them?