Make async futures `Unpin` if they don't borrow anything across `.await`s

[jplatte]

Am I missing something or could rustc in principle make the anonymous (return) type of async fn and async {} blocks implement Unpin (or maybe it should be "not implement !Unpin") if the body does not contain any borrows across .await points? I couldn't find an existing issue about this.

[JakobDegen]

This seems like it would cause problems regarding accidental breaking changes. Changing a function to now borrow something across an await point is an incredibly easy change to accidentally make and would result in the Unpin impl being removed from the return type.

An alternative would be to make it possible to explicitly mark that an async function/block should be Unpin (removing the possibility of an accidental breaking change). I don't see how to do this in function signatures without introducing an additional keyword though (pub unpin async fn or such) and that's probably not worth the effort.

[jplatte]

@JakobDegen I don't see how Unpin would be different to Send and Sync in this regard.

How about doing this only for async blocks? async fns will remain returning impl Future + !Unpin, and function authors that want to make it Unpin can specify the return type as impl Future + Unpin manually. I think this would not easily cause accidental breaking changes?

[jplatte]

function authors that want to make it Unpin can specify the return type as impl Future + Unpin manually

You mean by making it a regular fn and wrapping the entire body in async move {}? I think a similar strategy could be used to create an attribute macro that asserts Send / Sync / Unpin for async fn (not sure about async blocks, can proc-macro attrs be used on expressions?), but doing it manually would be super annoying.

You mean by making it a regular fn and wrapping the entire body in async move {}? That would be pretty annoying. I think a similar strategy could be used to create an attribute macro that asserts Send / Sync / Unpin for async fn (not sure about async blocks, can proc-macro attrs be used on expressions?), but doing it manually would be super annoying.

Yes, and I agree that could be annoying (sorry for not thinking of this point before commenting, stability itself is annoying)...
An attribute macro is also a good (maybe even better) idea (FYI attribute macros on expressions are currently nightly-only, tracking at #15701).

[jplatte]

I guess I'll create that then 😄

[jplatte]

The amount of code required is smaller than I expected. I've hardly tested it, but I think it should work: https://docs.rs/async_auto_traits/0.1

(Off-topic content removed)

It turns out that my suggestion has a breaking change hole because impl Future does not hide auto traits: if the function author forgot to + Unpin, it's still easy to cause accidental breaking changes. I didn't consider that point carefully before commenting. Sorry about that!

[jplatte]

That's kind of surprising but kind of not. Testing whether one can explicitly opt out via + ?Send or sth. like that would probably be a good next step. I'm out of time today but if nobody beats me to it will look into it tomorrow.

Looks like this can prevent the Future from implementing Send and Sync (play):

use std::{future, marker::PhantomData};

async fn foo() {
    future::ready(PhantomData::<*mut ()>).await;
}

fn assert_send_sync(_: impl Send, _: impl Sync) {}

fn main() {
    assert_send_sync(foo(), foo());
}

[jplatte]

Okay, let's move this discussion to an issue on https://github.com/jplatte/async_auto_traits.

@hyd-dev I suggest hiding your previous two comments here.