Non-exhaustive structs may be empty

[Nadrieril]

This is a follow-up to a discrepancy noticed in #122792: today, the following struct is considered inhabited (non-empty) outside its defining crate:

#[non_exhaustive]
pub struct UninhabitedStruct {
    pub never: !,
    // other fields
}

#[non_exhaustive] on a struct should mean that adding fields to it isn't a breaking change. There is no way that adding fields to this struct could make it non-empty since the never field must stay and is inconstructible. I suspect this was implemented this way due to confusion with #[non_exhaustive] enums, which indeed should be considered non-empty outside their defining crate.

I propose that we consider such a struct uninhabited (empty), just like it would be without the #[non_exhaustive] annotation.

Code that doesn't pass today and will pass after this:

// In a different crate
fn empty_match_on_empty_struct<T>(x: UninhabitedStruct) -> T {
    match x {}
}

This is not a breaking change.

r? @compiler-errors

[traviscross]

@rfcbot fcp merge

We discussed this in the triage meeting today. This sounded good to us. Let's do it via FCP since there's a one-way door here.

[pnkfelix]

Hey @Nadrieril , I skimmed over the PR and noticed that all the test cases touched here that involve never-typed field also had that same field always marked as pub.

Is there a pre-existing test for the case of a non-exhaustive struct with a non-pub field that is empty? (A situation I infer to be a case which we wish to continue erroring on...)

[rfcbot]

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[Nadrieril]

Hey @Nadrieril , I skimmed over the PR and noticed that all the test cases touched here that involve never-typed field also had that same field always marked as pub.

Is there a pre-existing test for the case of a non-exhaustive struct with a non-pub field that is empty? (A situation I infer to be a case which we wish to continue erroring on...)

There isn't a test for non_exaustive + private empty field anymore. You can see that I changed it because I didn't feel it was testing the interesting case (which is non_exhaustive + public empty field, i.e. what the FCP is about).

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[Nadrieril]

@rustbot ready

[compiler-errors]

@bors r+

[bors]

📌 Commit 6f6a6bc has been approved by compiler-errors

It is now in the queue for this repository.