Consider use of #[non_exhaustive]

[LPardue]

I'm sure if this is work the effort but about a year ago I tried to add HTTP/3 to the Version enum and we hit the problem with exhaustive matching. That was independently fixed by adding a __NonExhaustive variant see https://github.com/hyperium/http/blob/master/src/version.rs#L52

In Rust 1.40 the #[non-exhaustive] attribute was landed https://blog.rust-lang.org/2019/12/19/Rust-1.40.0.html#[non_exhaustive]-structs,-enums,-and-variants, so is there any benefit switching to that?

[carllerche]

This would need a breaking change release as it would bump the minimum supported Rust version

[LPardue]

Is that a no? 😀

Or does it mean this change can be rolled into a label for the next breaking change release?

No advocating for doing work just for the sake of it. Happy to close the issue if that's the best action.

[carllerche]

We can consider it for the next breaking release.

[tgross35]

I think there are at least two things that could be done without a breaking release:

• Error, as I mentioned here before seeing this issue: Expose error kind enum for matching? #188 (comment)
• http::response::Parts, instead of using a dummy private item

[riking]

The MSRV is high enough that #[non_exhaustive] can be used now, right?