Static async fn in traits by tmandry · Pull Request #3185 · rust-lang/rfcs · Git...

Copy link

Contributor

ibraheemdev commented 18 hours ago

I don't see anything mentioned about Sendness. Is requiring the future to be send a potential future extension?

kennytm commented 17 hours ago

i suppose that requires ability to name the type of the returned future, stated in the last section of the "Future possibilities".

trait Service2 {
    async fn request(&self, key: i32) -> Response
    where
        Self::request::Output: Send;
}

the RFC does need to state whether the default is Send or ?Send though. "letting the compiler automatically" is not an answer because the generic code don't know the impl.

async fn foo<S: Service>(s: &S) {
    let future = s.request(1);
    // can we assume `typeof(future): Send` or not?? 
    future.await;
}

tmandry commented 9 hours ago

i suppose that requires ability to name the type of the returned future, stated in the last section of the "Future possibilities".

That's right. There's a separate RFC being worked on to add this functionality and make it possible to write those bounds.

the RFC does need to state whether the default is Send or ?Send though. "letting the compiler automatically" is not an answer because the generic code don't know the impl.

There is no Send default. In cases like the example you gave this is rarely a problem in practice. The reason is that we leak auto traits from async fn (and any function with return position impl Trait). If you call foo with a type S where S::request::Output: Send, the future returned by foo will be Send and callers are allowed to rely on this.

The story with dynamic dispatch is more complicated; there you need explicit Send bounds. But we aren't tackling that in this RFC.