Future-proofing enums/structs with #[non_exhaustive] attribute

[clarfon]

This is a post-1.0 version of #757, changed to use an attribute instead of a dedicated syntax. This would allow crates to more easily mark enums as "non-exhaustive," requiring downstream crates to add a wildcard arm to matches, so that adding new variants is not a breaking change.

Additionally, this syntax is extended to structs as well.

Rendered

Edit: Updated rendered link to rfcs repo version.

[scottmcm]

Another thing in favour of #[non_exhaustive] on structs: the non-pub field prevents construction, whereas the attribute could allow it through FRU. That would allow extensible builders, with struct Builder { a: b, c: d, ..Default::default() }. And it has the same ergonomic advantages as with enum, allowing in-crate matching on the exact set of fields without the bonus non_exhaustive: (), and not needing it on in-crate construction either.

[clarfon]

Because you mentioned it: if there's enough support for it, I'd be more than happy to promote the struct/trait parts into the main RFC. I've mostly kept what's there small so that we can at least get the enum part in.

Part of the reason why I did that is also ensuring that we choose a name that would work for structs/traits if/when they get added too.

[KodrAus]

I like it 👍

This RFC cements the current state of the world with respect to exhaustive matching: where a producer's enum/struct declares itself unexhaustively matchable, and a consumer must respect that with a catch-all pattern. That sounds reasonable to me, because it's the only way for a producer to be sure additions are non-breaking.

If I understand the RFC correctly, the #[non_exhaustive] attribute isn't adding hidden fields or anything. ie it's not making observable changes beyond the match semantics in the consumer, so I think an attribute is a fine way to do this.

[sfackler]

I feel a bit uneasy about using an attribute to control this. I'd prefer .. I think. Attributes don't normally change the semantics of a type that significantly.

[dlight]

I feel a bit uneasy about using an attribute to control this. I'd prefer .. I think. Attributes don't normally change the semantics of a type that significantly.

A tangential comment: #[async] is exactly an attribute that will change the semantics (of a function) significantly. So I think the naming scheme of attributes #[non_exhaustive] and #[async] (and the possibility of other attributes like this) should be discussed together, for consistency.

[seanmonstar]

A tangential comment: #[async] is exactly an attribute that will change the semantics (of a function) significantly.

I'd kind of expect to eventually have keywords async and await, I must assume they are currently an attribute and macro is because that's the easiest to implement and explore. But probably not the place to have this discussion.

[kevincox]

Excellent writeup. This sounds like a great change to me.

[kevincox]

Excellent writeup. This sounds like a great change to me.

[kevincox]

I would argue that if you expect users to handle every case then this isn't for you. You should not use this attribute and bump your major version. A warning on not handling a particular case is also incredibly likely to be low-value noise.

[clarfon]

That's fair! I mostly carried this over from #757 because it was discussed a lot in the RFC there.

[kevincox]

This seems like a good idea to me. However in this case non-exhaustive seems a less relevant keyword word because it is usually used to describe matching. incomplete, extensible or will_extend now start to sound better and work for both.

[clarfon]

I'd also note here that the term "extensible" was used on the previous RFC.

[kevincox]

This concept seems sufficiently different to deserve a different attribute.

[whitequark]

I would say #[extensible] applies here just as well--as in extending the set of supertraits. In case we go for .. for enum and struct (which I think is a good idea), we could go with:

trait A: B + C + .. {}

[kevincox]

You are right. extensible does sound good. Not only for extending traits but also extending the provided methods. And when I do look at it that way it does seem fairly related.

[clarfon]

You're right that they seem sufficiently different, but I see them all as solving the same problem: instead of preventing a user from implementing/using something by creating a hidden field, this simply states that not all of the dependencies can be listed by the user.

[clarfon]

I feel a bit uneasy about using an attribute to control this. I'd prefer .. I think. Attributes don't normally change the semantics of a type that significantly.

That is fair! I mostly changed it to an attribute because at the time of the original RFC (#757), it was decided that adding extra syntax was not worth the benefits, and someone suggested that an attribute might be better.

That said, a lot has happened since the initial 1.0 release, and I think that people are more willing to accept a syntax addition for this now than when the original RFC was written.

[kennytm]

👍 extending this to structs, 👎 extending this to traits. The semantic change applied to traits is different enough that should take a different attribute or syntax (e.g. #[sealed]); I was expecting #[non_exhaustive] applied to traits means "this trait may gain additional methods in the future".

[kennytm]

If this RFC is accepted and stabilized, there should be a (clippy?) lint that suggests any C-like enum returned from extern function (-> E or &mut E) be annotated #[non_exhaustive], to prevent rust-lang/rust#36927 ("Match on repr(C) enum returned from C library with unknown value leads to UB").

[leodasvacas]

Another thing in favour of #[non_exhaustive] on structs: the non-pub field prevents construction, whereas the attribute could allow it through FRU.

@scottmcm I don't see how the attribute would allow FRU, to the contrary it should forbid FRU outside the module that defines the struct. This should be in the RFC.

[ubsan]

@kennytm that doesn't really make much sense. A match on a non-exhaustive enum outside the bounds would still be UB, and it's not uncommon for C enums to be treated like Rust enums - i.e., only within the bounds is okay.

[kennytm]

@ubsan a match on a non-exhaustive C-like enum, not arbitrary enum. This particular case should be definable.

[clarfon]

I'm pretty sure that casting an arbitrary integer to an enum, C-like or not, is undefined behaviour unless it corresponds to a valid variant. I don't think that annotating the enum differently is going to change this problem.

[scottmcm]

@leodasvacas Oops, you're absolutely correct. Allowing FRU would need it to use the alternative desugar. ("jFransham's Super-FRUs", I remember it being called...)

[le-jzr]

@clarcharr What makes it UB for C-like enums is that it fails the assumption that an exhaustive match will always execute one of its branches. If exhaustive match is impossible, missing labels pose no problem.

[le-jzr]

Or to put it simply, putting #[non_exhaustive] on C-like enum could be a statement that every value of the underlying integer type is valid, even if those values don't have labels. Insofar as that statement applies to all code, even within the same crate, which of course is not what's being proposed in this RFC.

[clarfon]

Note that the attribute does not say "all bit patterns of this enum are valid," only "more variants may be added in the future."

I don't think that this is a good solution to the problem you're suggesting.

[le-jzr]

The attribute says what the RFC says it says, and RFC is not merged yet. ;)

But yes, it's somewhat different, even if intimately related. The solution to C enum problem requires #[non_exhaustive], but it's a somewhat stronger guarantee. In particular, match code generation needs to ensure that all unnamed values fall into the wildcard branch, which is not necessarily true right now (as far as I know).

[Ericson2314]

I do want some "real" solution for this. I want to be able to machine-check semver comparability, and the "doc trick" will be ugly to implement for any tool which does that.

[Virtlink]

This solution would be welcome, as it's a non-breaking change for Rust 1.x. But I think it's the wrong way around.

Non-exhaustive should be the default. This allows a crate author to add new enum variants and add new public and private fields to a struct, without breaking user's code. Of course, this forces users to handle the case where enums are extended, prevents users from using the default constructor to construct a struct, and also prevent users from destructuring the struct.

If the author really wants to enable the user to construct and destruct structs and exhaustively match enums, they have to promise that they won't add members to the struct or enum by finalizing it through some keyword or attribute (or otherwise risk breaking user's code).

Maybe for Rust 2.0?

[bjorn3]

I thinkno_extern_impl is a better name, because exhaustivenes feels weird for traits.

[scottmcm]

@clarcharr Are there any updates from the FCP you plan to make to this?

[clarfon]

Sorry for the delays @petrochenkov and @scottmcm. I will try and update this tomorrow.

[aturon]

@clarcharr Ping on the updates?

[clarfon]

@aturon @scottmcm @petrochenkov Sorry for the delays; I've updated with the notes on FRU and the tuple struct constructor visibility. Is this good to merge?

[petrochenkov]

Hm, the decision was the opposite - FRU is not permitted with non_exhaustive structs (in other crates).
FRU (with current rules) is a promise to not add private fields to a struct, and we want to be able to add private fields to non_exhaustive structs.

[clarfon]

I thought that FRU still worked when structs have private fields?

[petrochenkov]

No :(

[clarfon]

Unless I'm misunderstanding, I tried this out on the playground and it seems to work: https://play.rust-lang.org/?gist=eabe36303f9da0ced44c237ca3b29d45&version=stable

[petrochenkov]

https://play.rust-lang.org/?gist=48760b36d43778b49725151313af6be5&version=nightly

[clarfon]

…right, I'll update the RFC.

[petrochenkov]

This needs to apply to unit structs as well.

[clarfon]

Will do; one sec.

[petrochenkov]

Well, this seems to be equivalent to 3d56889#r135395315, but I'd still prefer to use the same wording for tuple and unit structs.

[petrochenkov]

LGTM now 👍

[scottmcm]

Huzzah! The @rust-lang/lang team has decided to accept this RFC.

To track further discussion, subscribe to the tracking issue here: rust-lang/rust#44109

Thanks for the RFC, @clarcharr!