Tracking Issue for async_fn_in_trait, return_position_impl_trait_in_trait

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

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.

May I take a go at this?

@rustbot

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

@LeSeulArtichaut

@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.

@LeSeulArtichaut

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 ❤️

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

@fakedrake

@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

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

fix(deps): update rust crate syn to v2 (#2512)

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.

outside of a macro ↩
For some defintion of "work" including anything but copying parameters into the return value ↩
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 ↩

@zachs18

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.

Auto merge of rust-lang#115822 - compiler-errors:stabilize-rpitit, r=…

Switch to nightly rust for rust-lang/rust#91611

Set minimum Rust version.

Set 1.75 as minimal Rust version (#11821)

bump MSRV to 1.75 for RPITIT

chore: bump MSRV to `1.75.0`

Set 1.75 as minimal Rust version (#11821)

Navigation Menu

Repository navigation

Tracking Issue for async_fn_in_trait, return_position_impl_trait_in_trait #91611

About tracking issues

Steps

Unresolved Questions

Async fn in trait

Return position impl Trait in trait

Implementation history

Async fn in trait

Return position impl Trait in trait

30 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking Issue for async_fn_in_trait, return_position_impl_trait_in_trait #91611

Description

About tracking issues

Steps

Unresolved Questions

Async fn in trait

Return position impl Trait in trait

Implementation history

Async fn in trait

Return position impl Trait in trait

Activity

HTGAzureX1212 commented on Feb 5, 2022

LeSeulArtichaut commented on Mar 23, 2022

nikomatsakis commented on Mar 24, 2022

spastorino commented on Mar 24, 2022

LeSeulArtichaut commented on Mar 24, 2022

fakedrake commented on Sep 12, 2022

spastorino commented on Sep 13, 2022

30 remaining items

rakshith-ravi commented on Aug 20, 2023

zachs18 commented on Sep 13, 2023

Footnotes

compiler-errors commented on Sep 14, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions