---
title: "RPITIT is ready, async is not (but it's getting there)"
tags: T-lang, blog-post
date: 2023-09-21
url: https://hackmd.io/xy3aQ8XHTJePmjcky0WC_w
---

# New version: https://hackmd.io/0LAdFZ07Rf2oCxGDC79Nxw

---

# Impl trait in traits is ready, async fn is not (but it's getting close)

We here at wg-async are super excited to announce major progress towards our goal of enabling the use of `async fn` in traits. The next Rust release will include stable support for `-> impl Trait` notation in traits.

It will also include *limited* support for `async fn`. Async functions are still missing some crucial features that most users need. Those features are our next priority. In the meantime, if you use async fn in traits, you'll get a lint warning to make sure you are aware of the limitations.

## Returning `impl Trait`

Ever since [RFC #1522], Rust has allowed users to write `impl Trait` as the return type of (some) functions. This means that the function returns "some type that implements `Trait`". This is commonly used to return iterators, closures, or other types that are complex or even impossible to write explicitly:

[RFC #1522]: https://rust-lang.github.io/rfcs/1522-conservative-impl-trait.html

/// Given a list of players, return an iterator
/// over their names.
fn player_names(
    players: &[Player]
) -> impl Iterator<Item = &String> {
    players
        .iter()
        .map(|p| &p.name)
}

Starting in Rust 1.XX, you can now use return-position `impl Trait` in traits and trait impls. For example, you could use this to write a trait that returns an item:

trait Container {
    fn items(&self, url: Url) -> impl Iterator<Item = Widget>;
}

Implementing the trait works how you might expect:

impl Container for MyContainer {
    fn items(&self, url: Url) -> impl Iterator<Item = Widget> {
        self.items.iter().cloned()
    }
}

<!--tmandry note: I want the post to get to the point of "what do I do" quickly, so I don't think showing the desugaring here helps.-->
<!--
Under the hood, a return position `impl Trait` in a trait desugars to an anonymous [generic associated type][gat]:

[gat]: XXX

trait Container {
    type $items<'a>: Iterator<Item = Widget>;
    fn items(&self, url: Url) -> Self::$items<'a>;
}

impl Container for MyContainer {
    type $items<'a> = /* inferred by the compiler */;
    fn items(&self, url: Url) -> Self::$items<'a>  {
        self.items.iter().cloned()
    }
}

-->

## Async fn in traits work, but aren't ready for prime time

So what does all of this have to do with async functions? Well, async functions are "just sugar" for a function that returns `-> impl Future`. So, since that is now permitted in traits, we also permit you to write traits that use `async fn`...

trait HttpService {
    // Desugars to:
    // fn fetch(&self, url: Url) -> impl Future<Output = HtmlBody>
    async fn fetch(&self, url: Url) -> HtmlBody;
}

...but if you do that, you'll find that you get a warning:

XXX

The error message is asking you to make a choice: **Do you want your trait to work primarily with multithreaded work-stealing executors?**

We expect that for a majority of users today, the answer will be yes. If you do, rewrite the signature using `impl Future + Send` . If you only expect your trait to be used on single-threaded executors, you can elide the `+ Send` bound or silence the warning with `#[allow]`.

trait HttpService {
    fn fetch(&self, url: Url)
    -> impl Future<Output = HtmlBody> + Send;
}

If you want your trait to be generic over both, the only way *today* is to make two copies of your trait: One with `+ Send` bounds and one without.

We've published a proc macro to make all of this easier:

#[make_variant(HttpService: Send)]
trait LocalHttpService {
    async fn fetch(&self, url: Url) -> HtmlBody;
}

This creates two traits, `HttpService` and `SendHttpService`, one for each use case. Our hope is that in the future, `HttpService` will be the only trait people need, with `SendHttpService` being an additional convenience for users.

Read on for a more thorough explanation of the problem.
<!--tmandry: is there an earlier post we can link to?-->

## The "send bound" problem

Remember earlier that we talked about how impl Traits desugar to an anonymous associated type? Because that associated type is *anonymous*, it means that you can't name it in where-clauses, which in turn means that you cannot (yet) place additional constraints on it.

For many traits, this isn't a problem. But for async functions in particular, it can become a problem very quickly when you are using work-stealing executors (which is the most common configuration in practice). This is because work-stealing executors require not just a `Future` but a `Future` that is also `Send`. Because this is so common, we call the general problem of not being able to write bounds on the associated type the "send bound problem".

Let's explain the send bound problem with an example. Imagine that we are using [tokio][] and we wish to write some code that accepts any `HttpService` and spawns a new task using it:

[tokio]: https://tokio.rs

fn spawn_task<H: HttpService>(h: H) {
    tokio::spawn(async move {
        ... 
        let body = h.fetch(some_url).await; // ERROR
        ...
    });
}

This code will not compile:

XXX

The problem here is that, when we call `h.fetch`, we get back an `impl Future` -- but tokio requires a `impl Future + Send`, and so the compiler reports an error. Interestingly, this problem only occurs in a *generic* context -- if we call the `HttpService` methods with a known type, everything works fine:

struct MyService { ... }
impl HttpService for MyService { ... }

fn spawn_task_not_generic(h: MyService) {
    tokio::spawn(async move {
        ...
        let body = h.fetch(some_url).await; // OK
        ...
    });

}

Why is this? It's because in this case, the compiler knows *precisely* which impl you are using, and so it can check that the actual future is `Send`; in contrast, in the generic case, the compiler has to use the bounds declared in the trait, which don't include `Send`.

What we would *like* to have is some way to write a where-clause that specifies that you need not only an `HttpServer` but an `HttpServer` that returns a `Send` future. There are several proposals for how we might achieve this, but we don't yet have consensus on which is best. **The "send bound problem" is the main reason that we don't believe async functions in traits are ready for prime time.** Now that the core stabilization is complete, we are planning to focus on selecting, RFC'ing, and stabilizing a solution for "send bounds" ASAP.

## The other big limitation: dynamic dispatch

## The fine print

For those who really want to know the nitty gritty, there are a bunch of other interesting deatils that we worked through to reach this point.

### Mixing async fn and impl Trait

### Revealing and semver

When you use `-> impl Trait`

### Impl trait capture rules in traits vs elsewhere

We've also improved on the capture rules for `-> impl Trait` in traits. In inherent impls you might often write something like this:

impl Foo {
    fn foo(&self) -> impl Future<Output = i32> + '_;
}

That `+ '_` says that the returned future captures a reference to `self`. This can be a nuisance on its own, but it gets [really complicated][capture-rules] when there are multiple lifetimes involved.

[capture-rules]: https://hackmd.io/sFaSIMJOQcuwCdnUvCxtuQ?view

For _return-position `impl Trait` in traits_ we've adopted updated capture rules that we hope to roll out to language more broadly in the next edition. This means `+ '_` is **not** required in traits or trait impls.

## Recommendations

### When *should* you use return-position impl Trait in traits?

### When *should* you use async fn in traits?

## Conclusion: what's to come?

This next release marks a big milestone, but it's not the end of the road. Now that the rudiments are stabilized, we are turning our focus to solving the send bound problem and, after that, native support for dynamic dispatch.

Once that is resolved, we will remove the warning on the use of async fn, because we feel it is ready for widespread use. Of course, we're never satisfied, and

[send bound problem]: https://smallcultfollowing.com/babysteps/blog/2023/02/01/async-trait-send-bounds-part-1-intro/