Is async-std within the scope of this crate? about hyper-rustls HOT 2 OPEN

It seems like it should be quite simple to implement a connector based on this one that uses async-std types instead of tokio types.

It would really just be swapping tokio's AsyncRead/AsyncWrite traits for async-std's (and dealing with any API difference) and replacing tokio-rustls with async-tls (which despite the generic name is in fact a kind of async-std-rustls).

You could enable/disable them with feature flags rather than making a separate crate, but a separate crate might be tidier especially with regard to releasing updates in sync with async-std and async-tls.

If half the ecosystem is really moving over to async-std I'm sure someone will be motivated to make the few changes needed...

from hyper-rustls.

Do folks still feel this is a relevant issue ~three years in? From the perspective of someone newer to the Rust ecosystem it seems like a lot of the community has converged on Tokio.

from hyper-rustls.