`Uri::path()` and and `Uri::path_and_query()` have confusing semantics

[briansmith]

path() returns &str which means it is never missing. Then why does path_and_query() return Option<&str> instead of &str? In other words, if the path is never missing then how can path_and_query() ever be missing? Under what circumstances would path_and_query() return None?

path() returns * when the URI is *. This seems really error prone. Regardless, what does path_and_query() return when path() returns *? This should be documented.

I would expect that url.path_and_query().unwrap().starts_with(url.path()) never panics and is always true, and that url.path_and_query().unwrap() == url.path() + url.query().map(|q| "?" + q) never panics and is always true. That is, I would expect that url.path_and_query() never returns None.

[hawkw]

If the return type of Uri::path_and_query is intended to explicitly indicate when the query part is not present, I might expect it to return something like (&str, Option<&str>), where the path part is always returned and the query part is optional?

[carllerche]

@briansmith you're not wrong...

The various APIs evolved over time. There should definitely be a re-evaluation of how everything works.

The problem is the HTTP uri component always includes a path except when * or for CONNECT requests. This means that for 99% of the use cases, there will always be a path. As such, having uri.path() return Option is going to be pretty annoying.

The question is if there is a way to have an "easy" API for the 99% cases while still exposing the subtleties when you care.

One option (without an opinion of quality of the option) would be to switch Uri::path to panic if there isn't a path component present.

Also, currently path_and_query does not return a &str, but a ref to a PathAndQuery. It is None in the two cases above and Some otherwise.

[carllerche]

A question arises in hyperium/h2#228 (comment):

Should a URI that does not include a path default to /?