Tracking Issue for async_fn_in_trait, return_position_impl_trait_in_trait

[nikomatsakis]

• This is a tracking issue for the RFC "static async fn in traits" (Static async fn in traits rfcs#3185) and "Return position impl Trait in traits" (Return position impl Trait in traits rfcs#3425).
• The feature gate for async fn in traits is #![feature(async_fn_in_trait)].
• The feature gate for return position impl Trait in traits is #![feature(return_position_impl_trait_in_trait)].
• This feature is developed as part of the async fundamentals initiative -- see that website for more information!

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
• Adjust documentation (see instructions on rustc-dev-guide)
• Stabilization PR: Stabilize async fn and return-position impl Trait in trait #115822

Unresolved Questions

Async fn in trait

• Do we need Send bounds to stabilize async_fn_in_trait? #103854

Return position impl Trait in trait

• Should we stabilize this feature together with async fn to mitigate hazards of writing a trait that is not forwards-compatible with its desugaring?
• Resolution of RPITIT is allowed to name any in-scope lifetime parameter, unlike inherent RPIT methods #112194
  • Note that this might impact the desugaring, as described in this comment.
• Should we limit the legal positions for impl Trait to positions that are nameable using upcoming features like return-type notation (RTN)? (See this comment for an example.)

Implementation history

Async fn in trait

F-async_fn_in_trait Static async fn in traits

• Only generate closure def id for async fns with body #102244
• Split out async_fn_in_trait into a separate feature #100734

Return position impl Trait in trait

F-return_position_impl_trait_in_trait `#![feature(return_position_impl_trait_in_trait)]`

Several of these include code specific to async fn in trait.

• Initial implementation of return-position impl Trait in traits #101224
• Equate fn outputs when inferring RPITIT hidden types #101614
• Make compare_predicate_entailment no longer a query #101615
• Check that the types in return position impl Trait in traits are well-formed #101676
• Support default-body trait functions with return-position impl Trait in traits #101679
• Calculate ProjectionTy::trait_def_id for return-position impl Trait in trait correctly #102152
• Resolve async fn signature even without body (e.g., in trait) #102161
• Serialize return-position impl Trait in trait hidden values in foreign libraries #102164
• Avoid ICE in printing RPITIT type #102597
• Fix subst issues with return-position impl Trait in trait #102334
• Handle return-position impl Trait in traits properly in register_hidden_type #103355

[HTGAzureX1212]

May I take a go at this?

[LeSeulArtichaut]

Currently trying to take a stab at this. @rustbot claim

[nikomatsakis]

@LeSeulArtichaut actually, @spastorino has been looking into doing various refactorings to make this easier, you should probably synchronize with him, I'm not sure what state we are in.

[spastorino]

Ohh, unsure why I've never assigned this to myself. I've been working on this since a while, and I've implemented RPITIT and async fns in traits support partially. At some point, we've realized that we wanted to change the design of the solution and started doing some refactors on RPITs.
Anyway, I've already talked with @LeSeulArtichaut, and I'd be happy to share some work with them about this feature or about any other feature ❤️

[fakedrake]

It seems this has been asleep for a while, is it blocked? is it dead? Does it need more love?

[spastorino]

@fakedrake we are working on this thing, there's some support work being done by my RPIT Refactor and by RPITIT PR that just landed. You can see discussions on https://rust-lang.zulipchat.com/#narrow/stream/330606-wg-async.2Fasync-fn-in-trait-impl

[rakshith-ravi]

Is this still on track for 1.74, as mentioned by the blog post that had come out earlier?

[zachs18]

Currently (on stable), anywhere you see an async fn¹, you know that it does no "work"² when called, and only does work when .awaited or .poll()ed³. If it is allowed to manually desugar async fn in a trait definition as fn() -> impl Future in a trait impl, then this becomes no longer true, as one can insert computation into the function defintion, e.g.

trait Trait {
  async fn foo();
}
impl Trait for () {
  fn foo -> impl Future<Output = ()> {
    println!("Doing stuff!");
    async {}
  }
}

I don't think this is a "blocker" but perhaps that section of the async book and the reference could be updated to reflect this change.

Footnotes

1. outside of a macro ↩

2. For some defintion of "work" including anything but copying parameters into the return value ↩

3. This is my understanding at least, and it is somewhat supported by the async book and the Rust Reference: "The value returned by async fn is a Future. For anything to happen, the Future needs to be run on an executor." (emphasis mine) from the async book, and "Async functions do no work when called: instead, they capture their arguments into a future. When polled, that future will execute the function's body" (emphasis mine) from the Rust Reference ↩

[compiler-errors]

For the record, a stabilization PR has been opened over at: #115822.

#91611 (comment): @zachs18: Yeah, I think the async book should be adjusted to mention something along the lines of "future isn't, in general, gonna to be run to completion unless it is awaited" -- the point, afaict, is more to make sure folks know .await needs to be called on the future unlike other langs which spawn tasks and kick them off immediately as a part of their async desugaring or something.