8

Stabilize `async fn` and return-position `impl Trait` in trait by compiler-error...

 11 months ago
source link: https://github.com/rust-lang/rust/pull/115822
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Stabilization report

This report proposes the stabilization of #![feature(return_position_impl_trait_in_trait)] (RPITIT) and #![feature(async_fn_in_trait)] (AFIT). These are both long awaited features that increase the expressiveness of the Rust language and trait system.

Closes #91611

Updates from thread

The thread has covered two major concerns:

Stabilization Summary

This stabilization allows the following examples to work.

Example of return-position impl Trait in trait definition

trait Bar {
    fn bar(self) -> impl Send;
}

This declares a trait method that returns some type that implements Send. It's similar to writing the following using an associated type, except that the associated type is anonymous.

trait Bar {
    type _0: Send;
    fn bar(self) -> Self::_0;
}

Example of return-position impl Trait in trait implementation

impl Bar for () {
    fn bar(self) -> impl Send {}
}

This defines a method implementation that returns an opaque type, just like RPIT does, except that all in-scope lifetimes are captured in the opaque type (as is already true for async fn and as is expected to be true for RPIT in Rust Edition 2024), as described below.

Example of async fn in trait

trait Bar {
    async fn bar(self);
}

impl Bar for () {
    async fn bar(self) {}
}

This declares a trait method that returns some Future and a corresponding method implementation. This is equivalent to writing the following using RPITIT.

use core::future::Future;

trait Bar {
    fn bar(self) -> impl Future<Output = ()>;
}

impl Bar for () {
    fn bar(self) -> impl Future<Output = ()> { async {} }
}

The desirability of this desugaring being available is part of why RPITIT and AFIT are being proposed for stabilization at the same time.

Motivation

Long ago, Rust added RPIT and async/await. These are major features that are widely used in the ecosystem. However, until now, these feature could not be used in traits and trait implementations. This left traits as a kind of second-class citizen of the language. This stabilization fixes that.

async fn in trait

Async/await allows users to write asynchronous code much easier than they could before. However, it doesn't play nice with other core language features that make Rust the great language it is, like traits. Support for async fn in traits has been long anticipated and was not added before due to limitations in the compiler that have now been lifted.

async fn in traits will unblock a lot of work in the ecosystem and the standard library. It is not currently possible to write a trait that is implemented using async fn. The workarounds that exist are undesirable because they require allocation and dynamic dispatch, and any trait that uses them will become obsolete once native async fn in trait is stabilized.

We also have ample evidence that there is demand for this feature from the async-trait crate, which emulates the feature using dynamic dispatch. The async-trait crate is currently the #5 async crate on crates.io ranked by recent downloads, receiving over 78M all-time downloads. According to a recent analysis, 4% of all crates use the #[async_trait] macro it provides, representing 7% of all function and method signatures in trait definitions on crates.io. We think this is a lower bound on demand for the feature, because users are unlikely to use #[async_trait] on public traits on crates.io for the reasons already given.

Return-position impl Trait in trait

async fn always desugars to a function that returns impl Future.

async fn foo() -> i32 { 100 }

// Equivalent to:
fn foo() -> impl Future<Output = i32> { async { 100 } }

All async fns today can be rewritten this way. This is useful because it allows adding behavior that runs at the time of the function call, before the first .await on the returned future.

In the spirit of supporting the same set of features on async fn in traits that we do outside of traits, it makes sense to stabilize this as well. As described by the RPITIT RFC, this includes the ability to mix and match the equivalent forms in traits and their corresponding impls:

trait Foo {
    async fn foo(self) -> i32;
}

// Can be implemented as:
impl Foo for MyType {
    fn foo(self) -> impl Future<Output = i32> {
        async { 100 }
    }
}

Return-position impl Trait in trait is useful for cases beyond async, just as regular RPIT is. As a simple example, the RFC showed an alternative way of writing the IntoIterator trait with one fewer associated type.

trait NewIntoIterator {
    type Item;
    fn new_into_iter(self) -> impl Iterator<Item = Self::Item>;
}

impl<T> NewIntoIterator for Vec<T> {
    type Item = T;
    fn new_into_iter(self) -> impl Iterator<Item = T> {
        self.into_iter()
    }
}

Major design decisions

This section describes the major design decisions that were reached after the RFC was accepted:

  • EDIT: Lint against async fn in trait definitions

    • Until the send bound problem is resolved, the use of async fn in trait definitions could lead to a bad experience for people using work-stealing executors (by far the most popular choice). However, there are significant use cases for which the current support is all that is needed (single-threaded executors, such as those used in embedded use cases, as well as thread-per-core setups). We are prioritizing serving users well over protecting people from misuse, and therefore, we opt to stabilize the full range of functionality; however, to help steer people correctly, we are will issue a warning on the use of async fn in trait definitions that advises users about the limitations. (See this summary comment for the details of the concern, and this comment for more details about the reasoning that led to this conclusion.)

  • Capture rules:

    • The RFC's initial capture rules for lifetimes in impls/traits were found to be imprecisely precise and to introduce various inconsistencies. After much discussion, the decision was reached to make -> impl Trait in traits/impls capture all in-scope parameters, including both lifetimes and types. This is a departure from the behavior of RPITs in other contexts; an RFC is currently being authored to change the behavior of RPITs in other contexts in a future edition.

    • Major discussion links:

  • Refinement:

    • The refinement RFC initially proposed that impl signatures that are more specific than their trait are not allowed unless the #[refine] attribute was included, but left it as an open question how to implement this. The stabilized proposal is that it is not a hard error to omit #[refine], but there is a lint which fires if the impl's return type is more precise than the trait. This greatly simplified the desugaring and implementation while still achieving the original goal of ensuring that users do not accidentally commit to a more specific return type than they intended.

    • Major discussion links:

What is stabilized

Async functions in traits and trait implementations

  • async fn are now supported in traits and trait implementations.
  • Associated functions in traits that are async may have default bodies.

Return-position impl trait in traits and trait implementations

  • Return-position impl Traits are now supported in traits and trait implementations.
    • Return-position impl Trait in implementations are treated like regular return-position impl Traits, and therefore behave according to the same inference rules for hidden type inference and well-formedness.
  • Associated functions in traits that name return-position impl Traits may have default bodies.
  • Implementations may provide either concrete types or impl Trait for each corresponding impl Trait in the trait method signature.

For a detailed exploration of the technical implementation of return-position impl Trait in traits, see the dev guide.

Mixing async fn in trait and return-position impl Trait in trait

A trait function declaration that is async fn ..() -> T may be satisfied by an implementation function that returns impl Future<Output = T>, or vice versa.

trait Async {
    async fn hello();
}

impl Async for () {
    fn hello() -> impl Future<Output = ()> {
        async {}
    }
}

trait RPIT {
    fn hello() -> impl Future<Output = String>;
}

impl RPIT for () {
    async fn hello() -> String {
        "hello".to_string()
    }
}

Return-position impl Trait in traits and trait implementations capture all in-scope lifetimes

Described above in "major design decisions".

Return-position impl Trait in traits are "always revealing"

When a trait uses -> impl Trait in return position, it logically desugars to an associated type that represents the return (the actual implementation in the compiler is different, as described below). The value of this associated type is determined by the actual return type written in the impl; if the impl also uses -> impl Trait as the return type, then the value of the associated type is an opaque type scoped to the impl method (similar to what you would get when calling an inherent function returning -> impl Trait). As with any associated type, the value of this special associated type can be revealed by the compiler if the compiler can figure out what impl is being used.

For example, given this trait:

trait AsDebug {
    fn as_debug(&self) -> impl Debug;
}

A function working with the trait generically is only able to see that the return value is Debug:

fn foo<T: AsDebug>(t: &T) {
    let u = t.as_debug();
    println!("{}", u); // ERROR: `u` is not known to implement `Display`
}

But if a function calls as_debug on a known type (say, u32), it may be able to resolve the return type more specifically, if that implementation specifies a concrete type as well:

impl AsDebug for u32 {
    fn as_debug(&self) -> u32 {
        *self
    }
}

fn foo(t: &u32) {
    let u: u32 = t.as_debug(); // OK!
    println!("{}",  t.as_debug()); // ALSO OK (since `u32: Display`).
}

The return type used in the impl therefore represents a semver binding promise from the impl author that the return type of <u32 as AsDebug>::as_debug will not change. This could come as a surprise to users, who might expect that they are free to change the return type to any other type that implements Debug. To address this, we include a refining_impl_trait lint that warns if the impl uses a specific type -- the impl AsDebug for u32 above, for example, would toggle the lint.

The lint message explains what is going on and encourages users to allow the lint to indicate that they meant to refine the return type:

impl AsDebug for u32 {
    #[allow(refining_impl_trait)]
    fn as_debug(&self) -> u32 {
        *self
    }
}

RFC #3245 proposed a new attribute, #[refine], that could also be used to "opt-in" to refinements like this (and which would then silence the lint). That RFC is not currently implemented -- the #[refine] attribute is also expected to reveal other details from the signature and has not yet been fully implemented.

Return-position impl Trait and async fn in traits are opted-out of object safety checks when the parent function has Self: Sized

trait IsObjectSafe {
    fn rpit() -> impl Sized where Self: Sized;
    async fn afit() where Self: Sized;
}

Traits that mention return-position impl Trait or async fn in trait when the associated function includes a Self: Sized bound will remain object safe. That is because the associated function that defines them will be opted-out of the vtable of the trait, and the associated types will be unnameable from any trait object.

This can alternatively be seen as a consequence of #112319 (comment) and the desugaring of return-position impl Trait in traits to associated types which inherit the where-clauses of the associated function that defines them.

What isn't stabilized (aka, potential future work)

Dynamic dispatch

As stabilized, traits containing RPITIT and AFIT are not dyn compatible. This means that you cannot create dyn Trait objects from them and can only use static dispatch. The reason for this limitation is that dynamic dispatch support for RPITIT and AFIT is more complex than static dispatch, as described on the async fundamentals page. The primary challenge to using dyn Trait in today's Rust is that dyn Trait today must list the values of all associated types. This means you would have to write dyn for<'s> Trait<Foo<'s> = XXX> where XXX is the future type defined by the impl, such as F_A. This is not only verbose (or impossible), it also uniquely ties the dyn Trait to a particular impl, defeating the whole point of dyn Trait.

The precise design for handling dynamic dispatch is not yet determined. Top candidates include:

  • callee site selection, in which we permit unsized return values so that the return type for an -> impl Foo method be can be dyn Foo, but then users must specify the type of wide pointer at the call-site in some fashion.

  • dyn*, where we create a built-in encapsulation of a "wide pointer" and map the associated type corresponding to an RPITIT to the corresponding dyn* type (dyn* itself is not exposed to users as a type in this proposal, though that could be a future extension).

Where-clause bounds on return-position impl Trait in traits or async futures (RTN/ART)

One limitation of async fn in traits and RPITIT as stabilized is that there is no way for users to write code that adds additional bounds beyond those listed in the -> impl Trait. The most common example is wanting to write a generic function that requires that the future returned from an async fn be Send:

trait Greet {
    async fn greet(&self);
}

fn greet_in_parallel<G: Greet>(g: &G) {
    runtime::spawn(async move {
        g.greet().await; //~ ERROR: future returned by `greet` may not be `Send`
    })
}

Currently, since the associated types added for the return type are anonymous, there is no where-clause that could be added to make this code compile.

There have been various proposals for how to address this problem (e.g., return type notation or having an annotation to give a name to the associated type), but we leave the selection of one of those mechanisms to future work.

In the meantime, there are workarounds that one can use to address this problem, listed below.

Require all futures to be Send

For many users, the trait may only ever be used with Send futures, in which case one can write an explicit impl Future + Send:

trait Greet {
    fn greet(&self) -> impl Future<Output = ()> + Send;
}

The nice thing about this is that it is still compatible with using async fn in the trait impl. In the async working group case studies, we found that this could work for the builder provider API. This is also the default approach used by the #[async_trait] crate which, as we have noted, has seen widespread adoption.

Avoid generics

This problem only applies when the Self type is generic. If the Self type is known, then the precise return type from an async fn is revealed, and the Send bound can be inferred thanks to auto-trait leakage. Even in cases where generics may appear to be required, it is sometimes possible to rewrite the code to avoid them. The socket handler refactor case study provides one such example.

Unify capture behavior for -> impl Trait in inherent methods and traits

As stabilized, the capture behavior for -> impl Trait in a trait (whether as part of an async fn or a RPITIT) captures all types and lifetimes, whereas the existing behavior for inherent methods only captures types and lifetimes that are explicitly referenced. Capturing all lifetimes in traits was necessary to avoid various surprising inconsistencies; the expressed intent of the lang team is to extend that behavior so that we also capture all lifetimes in inherent methods, which would create more consistency and also address a common source of user confusion, but that will have to happen over the 2024 edition. The RFC is in progress. Should we opt not to accept that RFC, we can bring the capture behavior for -> impl Trait into alignment in other ways as part of the 2024 edition.

impl_trait_projections

Orthgonal to async_fn_in_trait and return_position_impl_trait_in_trait, since it can be triggered on stable code. This will be stabilized separately in #115659.

If we try to write this code without `impl_trait_projections`, we will get an error: 



  
     
        ->  


      
      = 
        ->   
        
    



  
     
        ->  


      
      = 
        ->  <   >

Tests

Tests are generally organized between return-position impl Trait and async fn in trait, when the distinction matters.

Remaining bugs and open issues

(Nightly) Return type notation bugs

RTN is not being stabilized here, but there are some interesting outstanding bugs. None of them are blockers for AFIT/RPITIT, but I'm noting them for completeness.

Alternatives

Do nothing

We could choose not to stabilize these features. Users that can use the #[async_trait] macro would continue to do so. Library maintainers would continue to avoid async functions in traits, potentially blocking the stable release of many useful crates.

Stabilize impl Trait in associated type instead

AFIT and RPITIT solve the problem of returning unnameable types from trait methods. It is also possible to solve this by using another unstable feature, impl Trait in an associated type. Users would need to define an associated type in both the trait and trait impl:

trait Foo {
    type Fut<'a>: Future<Output = i32> where Self: 'a;
    fn foo(&self) -> Self::Fut<'_>;
}

impl Foo for MyType {
    type Fut<'a> where Self: 'a = impl Future<Output = i32>;
    fn foo(&self) -> Self::Fut<'_> {
        async { 42 }
    }
}

This also has the advantage of allowing generic code to bound the associated type. However, it is substantially less ergonomic than either async fn or -> impl Future, and users still expect to be able to use those features in traits. Even if this feature were stable, we would still want to stabilize AFIT and RPITIT.

That said, we can have both. impl Trait in associated types is desireable because it can be used in existing traits with explicit associated types, among other reasons. We should stabilize this feature once it is ready, but that's outside the scope of this proposal.

Use the old capture semantics for RPITIT

We could choose to make the capture rules for RPITIT consistent with the existing rules for RPIT. However, there was strong consensus in a recent lang team meeting that we should change these rules, and furthermore that new features should adopt the new rules.

This is consistent with the tenet in RFC 3085 of favoring "Uniform behavior across editions" when possible. It greatly reduces the complexity of the feature by not requiring us to answer, or implement, the design questions that arise out of the interaction between the current capture rules and traits. This reduction in complexity – and eventual technical debt – is exactly in line with the motivation listed in the aforementioned RFC.

Make refinement a hard error

Refinement (refining_impl_trait) is only a concern for library authors, and therefore doesn't really warrant making into a deny-by-default warning or an error.

Additionally, refinement is currently checked via a lint that compares bounds in the impl Traits in the trait and impl syntactically. This is good enough for a warning that can be opted-out, but not if this were a hard error, which would ideally be implemented using fully semantic, implicational logic. This was implemented (#111931), but also is an unnecessary burden on the type system for little pay-off.

History

Non-exhaustive list of PRs that are particularly relevant to the implementation:

Doc co-authored by @nikomatsakis, @tmandry, @traviscross. Thanks also to @spastorino, @cjgillot (for changes to opaque captures!), @oli-obk for many reviews, and many other contributors and issue-filers. Apologies if I left your name off 😺


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK