Jeremiah Senkpiel
Jeremiah Senkpiel
@yoshuawuyts Hey I would like to merge this tomorrow if there is no objection
Made one additional change to this... all the enums are `#[non_exhaustive]` now so we can add more cases in minors where it fits well
@yoshuawuyts if you are going to write a bunch of typed headers could you please take a look at this first?
> I haven't read the diff, but just a quick though since future API breakage seems to be a strong concern here. Consider making all the concrete enums nonexhaustive. That...
Related: `Request` does the same thing but for `Url`. https://github.com/http-rs/http-types/blob/539638273de768a24354b65999ad9317b6659204/src/request.rs#L47-L54 I'm not sure what the correct answer is here - do we make `::new()` return a `Result`? Do this in...
Related: making `Request::new()` or `Response::new()` return a `Result` makes the bounds complain that the errors are not `Send`/`Sync` (I forget which).
> and current Error already must include valid StatusCode That would just be 500 in the case of a Response.
Hmm, I'm not sure if that is the correct way to go. However, something occurred to me while reading that: we can take better advantage of Rust enums' ability to...
Hmm, That's unfortunate. Perhaps `StatusCode` should look like: ```rust pub enum StatusCode { Unknown(u16), Continue, BadRequest, // ... etc } ``` With custom overloads for `as`, etc to make it...
The PR for this will probably be quite small but will only be acceptable once we've gathered all the other semver-major changes, so it may sit for a while and...