Make async futures Unpin if they don't borrow anything across .awaits

[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.

[ghost]

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.

[ghost]

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

[ghost]

(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]

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.

[Dylan-DPC]

Closing this as it's better tracked in the jplatte/async_auto_traits#1 issue, and it is better to have it contained in one issue instead of having 2 issues tracking it in different places

[jplatte]

@Dylan-DPC I think you misunderstood something, that is about preventing the leak of auto-traits of async fn future types. It only relates to Unpin in that it would sometime be useful to be able to stop leaking an Unpin implementation in a public interface if the compiler generated those impls at all (which this issue is about).

[djc]

I was experimenting today with replacing the likes of futures_util::future::ok() (which is IMO a little ugly -- it reeks of the futures 0.1 times) with async move {} blocks and was surprised that I needed an explicit pin!() call wrapped around the async move {} block even with trivial Copy types (like usize).