Should "__Nonexhaustive" enum variant be recommended for future proofing?

[kjetilkjeka]

The __Nonexhaustive variant pattern is useful for allowing enums to grow post release. One example of use from the standard library is std::io::ErrorKind, and a constructed example follows this paragraph. Should this pattern be mentioned in the guidelines under future proofing?

pub enum Example {
    Variant1,
    Variant2,
    // Omitted variants
    VariantN,
    /// A marker variant that tells the compiler that users of this enum cannot match it exhaustively.
    #[doc(hidden)]
    __Nonexhaustive,
}

[Ixrec]

Note that there's an accepted RFC for a #[non_exhaustive] attribute for precisely this use case: rust-lang/rust#44109 But once that's implemented, I'd agree that an API guideline for using it would be good.

[kjetilkjeka]

I was not aware of this RFC, it looks like the feature will be stabilized soon. I agree that it's a good idea to wait for this then.

[jonas-schievink]

#[non_exhaustive] is now stable.

[KodrAus]

I think we should definitely be recommending #[non_exhaustive] on structs and enums with public fields or variants.

[dtolnay]

For the nonexhaustive enums in Syn, #[non_exhaustive] is unusable until rust-lang/rust#44109 (comment) gets implemented.