Is async-std within the scope of this crate?

[CryZe]

It seems to be possible to use hyper with async-std if you provide a Connector for it that uses async-std. Considering half the ecosystem is seemingly moving to async-std and tokio doesn't play well with async-std, there should probably be a good rustls based Connector that can be used in that case. I'm not sure if that is within the scope of hyper-rustls or if we need a second hyper-rustls-async-std.

[jbg]

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

[cpu]

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.