-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Private enum variants #32770
Comments
AFAIR, private variants/variant fields/trait items were considered rarely necessary and nobody wanted to make them private by default, and at the same time nobody wanted to revive |
@SimonSapin This is indeed a There are a couple ways we might go about this:
Given that we've already accepted the new privacy mechanism, I suspect that'll be the way to go here. (Of course, it still needs to be implemented!) |
@aturon RFC 1422 didn't address enums. Is |
@durka Ah! You're right, the RFC's detailed design only covers an expansion of the grammar for places that currently permit I had always assumed that this RFC would also introduce new locations for Paging @rust-lang/lang! |
@aturon I am in favor of permitting |
Another possibility for a dedicated mechanism is an attribute on the enum to control whether or not exhaustive matches are allowed, e.g. |
I’m not a fan of |
For compareason with other languages, OCaml has a lint that a lot of people use that warns (or errors, depending on the flags passed to the compiler) about There is also another (newer) feature: open variants. type my_variant = ..
my_variant += Foo(int)
my_variant += Bar(string) New variants can be added anywhere, even in other modules. The OCaml also has variants with |
I'm going to close this in favor of rust-lang/rfcs#943. |
https://stackoverflow.com/questions/36440021/whats-purpose-of-errorkind-nonexhaustive explains why the
std::io::ErrorKind
enum has this variant:It is to force users to have a catch-all
_
arm when matching on anErrorKind
value, so that more variants can be added in the future.Clearly this is a future-proofing mechanism that is useful. There is no reason it wouldn’t be as useful in external libraries on crates.io than in the standard library. But to achieve it,
ErrorKind
abuses the stability mechanism with#[unstable]
, which can only be used in the standard library.I’m sure this was discussed before, but a quick search did not show why we don’t allow variants of the same enum to have different privacy/visibility with
pub
orpriv
keywords, like we do for struct fields. Given the above, should this be reconsidered?CC @aturon & lang team
The text was updated successfully, but these errors were encountered: