You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a roadmap item for wg-async. You can view the roadmap here: wg-async roadmap
Allow -> impl Trait methods in traits, e.g.
traitIterable{fniter(&self) -> implIterator;}
Open questions
Semver hazard caused by auto trait leakage
Auto traits leak from public functions using async fn and return-position impl Trait. This is a pre-existing issue.
Once we make these features available within traits we have a chance to proactively make sure crate authors don't accidentally stabilize auto traits. For example, we could make it a lint or a hard error if you have a publicly-accessible function that is not explicit about its auto traits.
It's obvious how to do this for -> impl Trait (add + Send and probably #[refine]), but not async fn. We could also punt on this and make it a lint for all uses of -> impl Trait later (not only inside traits), upgrading to a hard error over an edition.
This is a roadmap item for wg-async. You can view the roadmap here: wg-async roadmap
Allow
-> impl Traitmethods in traits, e.g.Open questions
Semver hazard caused by auto trait leakage
Auto traits leak from public functions using
async fnand return-positionimpl Trait. This is a pre-existing issue.Once we make these features available within traits we have a chance to proactively make sure crate authors don't accidentally stabilize auto traits. For example, we could make it a lint or a hard error if you have a publicly-accessible function that is not explicit about its auto traits.
It's obvious how to do this for
-> impl Trait(add+ Sendand probably#[refine]), but notasync fn. We could also punt on this and make it a lint for all uses of-> impl Traitlater (not only inside traits), upgrading to a hard error over an edition.