Today the libs team along with our guests @seanmonstar, @KodrAus and @stephanbuys met to talk about the
When is it okay to use private types in the public API?
There are three cases where the reqwest public API refers to types that are private - meaning they cannot be named by any code outside of reqwest.
One of the three was unintentional and we just need to publicly expose the types involved (reqwest#105).
The other two cases were intentional but result in confusing rustdoc documentation. We will need to make changes to keep the intended behavior but make the rustdoc more easily understandable (hyper#1194 and reqwest#106). There may also be a way that rustdoc could improve this situation (rust#42323).
We will clarify these private-in-public patterns as an API guideline (guidelines#73).
Do &Error trait objects need to be Send and Sync?
It probably doesn't matter. For consistency with
io::Error we will change this in reqwest (reqwest#107) and also clarify the applicable API guideline (guidelines#80).
Are the StatusCode and HttpVersion enums a compatibility hazard?
Yes. New HTTP status codes and versions will be added in the future and we would not want that to require a breaking change in hyper or reqwest.
Associated constants will be stable soon so we will switch to those (hyper#1195).
What are the stability implications of re-exporting types from hyper?
Reqwest would like to release a stable version. Currently reqwest re-exports the Method, StatusCode, and HttpVersion types from hyper, so it couldn't be stable until hyper is stable. Stable hyper is waiting on stable tokio. Stable tokio is not imminent.
We will resolve this by factoring some of the foundational types like
StatusCode into a separate crate that can be stabilized sooner than all of hyper (hyper#1196).
How to deal with fallible methods on a builder that takes self by value?
The existing RequestBuilder was designed before Rust's question mark feature. It is a self-by-value builder with fallible methods that pretend to be infallible by stashing away an error until the request is about to be dispatched.
In today's Rust this would be more ergonomic as a &mut self builder with fallible methods (reqwest#108).
This calls for some API guidelines updates as well (guidelines#81 and guidelines#82 and guidelines#83).
What is the deal with html_root_url?
It is annoying and limited, and a small amount of tooling work could go a long way (rust#42300 and rust#42301).
Isn't there a better name for this crate?
reqwest is a great name.
Do we really want CI badges on crates.io?
Probably. But there is a lot of work we need to ask from the infrastructure team before the badges would be as meaningful as we would like. @sfackler will follow up.