Could we move away from naming one of the clients "defacto-default"? i.e. Calling them: reqwest::AsyncClient and reqwest::Client implies that the sync client is the default and async is somehow special and warrants investigation.
Using reqwest::AsyncClient and reqwest::SyncClient would be equally ergonomic, and allocates zero preference towards either implementation.
As per our exchange on reddit, we could do the following:
#[deprecated(note = "renamed to SyncClient")]
pub type Client = SyncClient;
P.S. As long as there isn't much opposition to this idea, this change is easy enough, I'm happy to do it if needed.
I'd be completely fine with this change, though it probably would be best to wait until there is more than just the blocking Client, otherwise the additional part of the name is just noise until then.
Sean's comment on #120 makes me think it'd be a good idea to do this rename prior to 1.0 even if there is only one kind of client just so the name for the sync client won't need to change between 1.0 and 2.0. There will be more people with existing code using whatever the sync client is called then than there are now.
@seanmonstar Do you have a roadmap for stablizing the async stuff?
@knight42 part of the issue is that futures and tokio are unstable, so that's the first blocker to being able to stabilize the async API in reqwest.
The default reqwest::Client is now async, with the "sync" client moved to reqwest::blocking::Client.
Most helpful comment
I'd be completely fine with this change, though it probably would be best to wait until there is more than just the blocking
Client, otherwise the additional part of the name is just noise until then.