Specify whether Futures returned by async fn's are Send

[jbe]

@quinedot

The more general "does the return implement an auto-trait" issue is also not async/RPIT specific.

Yeah, I found this link enlightening:

@quinedot

async fn is sugar for an RPIT, and RPIT is leaky around auto-traits such as Send, ^[1] just like nominal structs are.

It says:

• Low real change, since the situation already somewhat exists on structs with private fields:

  • In both cases, a change to the private implementation might change whether a OIBIT is implemented or not.
  • In both cases, the existence of OIBIT impls is not visible without documentation tools
  • In both cases, you can only assert the existence of OIBIT impls by adding explicit trait bounds either to the API or to the crate's test suite.

I always thought it's a particular problem of async fn, but it's not.

@quinedot

Include run() as a #[test], or just desugar it and add the bound yourself.

    pub fn foo() -> impl std::future::Future<Output = ()> + Send {
        async {
            nop().await;
        }
    }

Desurgaring only works when the Send bound doesn't depend on a type argument. So this can't be solved with desugaring: pub async fn foo<T>(value: T), which is Send if and only if T is Send. I guess this may be a problem for async traits also in the future.

I will resort to adding tests then to ensure that certain methods are Send if this is relevant, and possibly add a guarantee to the documentation. Or ignore the problem and hope nothing bad happens.

---

1. OIBIT is another term for auto-trait ↩︎