#[non_exhaustive] on variant blocks cross-crate as casts

[lambinoo]

Fixes: #1250

Adding missing documentation after changing in rust-lang/rust#91161 (rust-lang/rust#92744)

[ehuss]

Thanks!

[ehuss]

Thanks!

[mixy1]

Is this still the case as of today?

pub use keyboard_types::{Code, Modifiers};

fn main() {
    let key: Code = Code::KeyR;
    println!("{}", key as u32);
}

Works just fine, https://docs.rs/keyboard-types/latest/keyboard_types/enum.Code.html and it's indeed marked as non-exhaustive.

[obi1kenobi]

A quick check in the playground confirms the rule is a bit more involved, and the reference is inaccurate: playground (make sure to run "test" not "build")

/// ` ``rust
/// use playground::Example;
///
/// let value = Example::default();
/// println!("{}", value as isize)
/// ` ``
#[non_exhaustive]  // it doesn't matter whether this is commented-out or not
#[derive(Default)]
pub enum Example {
    #[default]
    First,
    
    // uncommenting the next line breaks the doctest:
    // #[non_exhaustive]
    Second,
}

The reference states that "it's also not allowed to cast non-exhaustive types from foreign crates" and gives an example of (failing while) casting the value of a non-exhaustive enum. This is inaccurate.

Per my example above, the rule as implemented today appears to be "it's not allowed to cast enums from foreign crates if the enum contains a non-exhaustive variant."

In the case of keyboard_types, the Code enum is non-exhaustive but all its variants are exhaustive, so under my inferred rule it's allowed. I agree that the reference seems to say that wouldn't work, and I assume a PR would be welcome. Just a note that RustConf is this week, so feedback on the PR would likely be delayed.

[obi1kenobi]

It may also be a good idea to update the reference page on enum variants and discriminants, since the section that describes numeric as casting doesn't mention #[non_exhaustive] at all: https://doc.rust-lang.org/reference/items/enumerations.html#casting

In cargo-semver-checks, we were just in the middle of implementing some new lints for numeric as casting of enums based on that reference page. After reading that page, I didn't know about the #[non_exhaustive] rule for variants until trying it in the playground just now, which is less than ideal 😅

[mixy1]

Not sure if this is the right place to ask, but what's the point of marking a variant as non_exhaustive? It intuitively makes sense to mark the enum as non_exhaustive but I can't understand why one would use it for a variant.

[obi1kenobi]

It can't be constructed by any downstream crate, and pattern-matching it requires allowing for extra fields with .. since exhaustive matching is disallowed. This means it can have additional fields added to it without causing an exhaustiveness-related major breaking change.

[mixy1]

I've opened PR #1607