Introducing the dedicated windows-future crate

[kennykerr]

Building on windows-collections #3483 and windows-numerics #3488, this update adds the windows-async crate that provides dedicated support for Windows asynchronous programming interfaces in Rust including stock implementations for ready and spawn to easily implement the various async operations as well as std::future implementations of Future and IntoFuture for all of the async interfaces to allow seamless interop with Rust futures-based libraries.

This builds on the overhaul of async future support in #3213 as well as the stock implementations of ready and spawn I introduced in #3221 and #3235.

The only snag is that @saelay published the windows-async crate in 2021 which appears to be unused and unmaintained. Unfortunately I have been unable to reach @saelay via a GitHub issue or email and this user does not appear to be active on GitHub any longer - March 2022 was the last sighting - so I'm unsure about how to take ownership of this crate registration so that I can use it for the Windows async support provided here. Worst case I have to find another name but that would not be ideal since this is all about providing support for IAsyncAction, IAsyncOperation, IAsyncOperationWithProgress, and IAsyncActionWithProgress so any other name would not be very discoverable.

[kennykerr]

Any suggestions for dealing with abandoned crate names? The best alternative I can think of is windows-future. It's frustrating that you can't reserve a prefix like windows-* on crates.io...

@ChrisDenton @robmikh @riverar

Update: or maybe windows-sync named after std::sync.

[ChrisDenton]

The best you can probably do is to try to contact the author and ask if they'd be willing to transfer ownership of the crate. You may be able to ask crates.io to facilitate this but I'm not sure what their current policy is on that. crates.io namespaces are in the works but likely not any time soon.

Of those options, windows-future sounds better to me. While windows-sync has the benefit of being succinct, it does sound like the opposite of what this does so I'm not sure about that. And I guess windows-iasync is getting a bit too close to letter salad.

[damyanp]

crates.io does have a policy documented for this: https://crates.io/policies#package-ownership

[riverar]

The lack of namespacing on crates.io is very unfortunate indeed.

Although futures terminology is not common in the Windows developer ecosystem, I agree with @ChrisDenton it's the best option presented thus far.

[kennykerr]

Thanks for the feedback all - sounds like windows-future, named after std::future, is the next best thing.

[riverar]

You could also consider spelling out async, windows-asynchronous. Just throwing it out there.

[kennykerr]

There's a reason it's always shortened to "async". 🫠

[robmikh]

Agreed that windows-future seems the best option. The future terminology doesn't really show up in WinRT, but at the same time if someone is using Rust I'm hoping they've already come across it.