[est31]

For enums at least, I'm not recommending it's use (yet), as with _Nonexhaustive you can make sure you caught all cases internally. Matching on _Nonexhaustive as a user of the library is of course a bad idea. There've been proposals to a lint like #[deny(reachable)] to make such checks possible for #[non_exhaustive] as well but it seems that nothing has happened yet: https://github.com/rust-lang/rust/issues/44109#issuecomment-...

[kibwen]

> For enums at least, I'm not recommending it's use (yet), as with _Nonexhaustive you can make sure you caught all cases internally.

I don't think this is necessary. The attribute in question is applied to an enum variant, and that variant's constructor is then given only crate-wide visibility. This looks to be simply a compiler-enforced codification of the pattern you're describing.

[est31]

It can both be applied to enum variants as well as to entire enums. I meant the latter case. From the release announcement:

> A perhaps more important aspect of #[non_exhaustive] is that it can also be attached to enums themselves. An example, taken from the standard library, is Ordering

For example, take this _Nonexhaustive enum case here: https://github.com/est31/rcgen/blob/d6b84d3d9d51b088dd672975...

A little bit further down, I'm matching on the enum in the to_oid function. I'd prefer if I got an error or at least a warning pointing to the match if I added a new enum case and didn't update the match statement.

[Nemo157]

non_exhaustive only affects downstream code, within the crate you can still treat it exhaustively. For example in this playground[0] if you build in test mode the match works inside the crate, but fails in the doc-test because that is treated as external code.

[0]: https://play.rust-lang.org/?version=stable&mode=debug&editio...

[est31]

Oh that's an interesting point, I didn't know that. I guess I'll use #[non_exhaustive] then after all.

[glandium]

How about using #[cfg_attr(test, non_exhaustive]?