#[non_exhaustive] attribute can cause another crate to stop compiling” github.com/rust-lang/reference/pull/1837#discussion_r2630423434
#[non_exhaustive] attribute can cause another crate to stop compiling” 

flori_ava_star:~
@star@amazonawaws.com#[non_exhaustive] has always been a breaking API change for your crate if I am not mistaken?
#[non_exhaustive] would be a breaking change, because you’re essentially adding a “imagine there are more variants you don’t know about”.#[non_exhaustive] is essentially providing more guarantees: “I’m done changing this type, you can rely on it not getting any extra variants in the future”.#[non_exhaustive] attribute can be a breaking change on e.g. current stable Rust?


flori_ava_star:~
@star@amazonawaws.com#[non_exhaustive], you’re giving the users of your library strictly more guarantees. the only thing it affects is “if you’re pattern matching on the enum, you need a wildcard”, or at least that’s the story we want to tell even though right now there are some subtleties in the lowering to MIR that we’re working out.#[non_exhaustive] is there. the purpose of this attribute is to give the author of the library more freedom in how they want to change the API between versions. there’s no way to write code that relies on “this enum might have more variants in the future”. that just doesn’t make sense.#[deny(...)] and then if the #[non_exhaustive] is removed, the branch will become statically unreachable and the compiler will give you a warning that will turn into an error? but I’d expect this to explicitly be a “you brought this upon yourself” carveout in the stability guarantees