> 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.
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
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.
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.
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.