expose std::pin

[yoshuawuyts]

This is important when defining / calling futures, so it makes sense for us to also export this.

But also given recent user feedback on the confusion on pinning, I'd like to open up the possibility to experiment with providing better pinning facilities such as pin-project or pin_mut behind flags. I'm not sure if we could, or even should. But I want to allow us to have that conversation and test things out (even if it's just in floating patches.)

Thanks!

[ghost]

The module is not behind the unstable flag :)

[yoshuawuyts]

The module is not behind the unstable flag :)

Oh yeah accurate; I was thinking pin::Pin is fine exactly the way it is because it's part of std and we already use it. Any addition to this module would be behind an unstable flag.

[ghost]

I'm not that sure we should expose std::pin yet and would still prefer having the whole module behind unstable.

This is important when defining / calling futures, so it makes sense for us to also export this.

Defining and calling futures is something users should rarely do (ideally, never!) - after all, the promise of async/await is that we don't write futures by hand anymore. And even if we still do write them by hand from time to time today, I expect that to be less and less the case over time.

Another point is that pinning is not that much related to async programming, and is an orthogonal feature that has more to do with generators. But I admit that, practically speaking, pinning is very closely tied to futures right now.

There are also std::marker::Unpin and std::marker::PhantomPinned, without which the "pinning story" would be incomplete. Imagine someone having the following imports in their code:

use std::marker::PhantomPinned;
use async_std::pin::Pin;

Why is Pin here in async_std but PhantomPinned is not? I worry that might be confusing.

[yoshuawuyts]

@stjepang those are all valid points, and I agree. I'll put the whole module behind an unstable flag!

[yoshuawuyts]

all feedback implemented. bors r+

[taiki-e]

@yoshuawuyts: It seems bors could not recognize your comment as a command.

https://bors.tech/documentation/

Also, the command will be recognized if, and only if, the word “bors” is at the beginning of a line.

[yoshuawuyts]

bors r+

[bors]

Build succeeded

• continuous-integration/travis-ci/push

[ghost]

Would it make sense to experiment with pin_mut! or #[pin_project] in async-macros/async-attributes? That feels to like a more appropriate place to me than async-std since those macros are not really "async version of Pin".

I'd love to collect all kinds of nice stuff there like #[test], #[bench], #[main], #[pin_project], #[throws], #[async_trait], #[for_await], etc. And we would be able to iterate quickly without worrying about stability - breaking changes are perfectly fine because these attributes are just syntax sugar.

But anyways, just thinking out aloud - let's keep async_std::pin as it is :)

[yoshuawuyts]

@stjepang Hell yes!