-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
RFC: Remove the priv
keyword
#26
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,82 @@ | ||
- Start Date: 2014-03-31 | ||
- RFC PR #: (leave this empty) | ||
- Rust Issue #: (leave this empty) | ||
|
||
# Summary | ||
|
||
This RFC is a proposal to remove the usage of the keyword `priv` from the Rust | ||
language. | ||
|
||
# Motivation | ||
|
||
By removing `priv` entirely from the language, it significantly simplifies the | ||
privacy semantics as well as the ability to explain it to newcomers. The one | ||
remaining case, private enum variants, can be rewritten as such: | ||
|
||
```rust | ||
// pub enum Foo { | ||
// Bar, | ||
// priv Baz, | ||
// } | ||
|
||
enum Foo { | ||
Bar, | ||
Baz(BazInner) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Won't this run afoul of the private type in public API lint? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No, There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oops, I misread. Why can't Even if it can't be instantiated, it still means that There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. With RFC 4 (private fields), the unit tuple is a private field, so it can't be instantiated. It's true that it can't be emulated exactly, it's mostly just a rough approximation. It's a good point though, and I hadn't realized it. Today, if you have a private variant (and therefore can't match against it), you can never exhaustively match on the enum outside the module. This means that enums with private variants can have variants added backwards-compatibly. With this RFC, no enum could have variants added backwards compatibility (guaranteed) because you could still list the public name. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah! I don't think this case is worth worrying too much about supporting exactly. I can't imagine a sane use case for partially-visible variants :) |
||
} | ||
|
||
pub struct BazInner(()); | ||
|
||
// pub enum Foo2 { | ||
// priv Bar2, | ||
// priv Baz2, | ||
// } | ||
|
||
pub struct Foo2 { | ||
variant: FooVariant | ||
} | ||
|
||
enum FooVariant { | ||
Bar2, | ||
Baz2, | ||
} | ||
``` | ||
|
||
Private enum variants are a rarely used feature of the language, and are | ||
generally not regarded as a strong enough feature to justify the `priv` keyword | ||
entirely. | ||
|
||
# Detailed design | ||
|
||
There remains only one use case of the `priv` visibility qualifier in the Rust | ||
language, which is to make enum variants private. For example, it is possible | ||
today to write a type such as: | ||
|
||
```rust | ||
pub enum Foo { | ||
Bar, | ||
priv Baz | ||
} | ||
``` | ||
|
||
In this example, the variant `Bar` is public, while the variant `Baz` is | ||
private. This RFC would remove this ability to have private enum variants. | ||
|
||
In addition to disallowing the `priv` keyword on enum variants, this RFC would | ||
also forbid visibility qualifiers in front of enum variants entirely, as they no | ||
longer serve any purpose. | ||
|
||
### Status of the identifier `priv` | ||
|
||
This RFC would demote the identifier `priv` from being a keyword to being a | ||
reserved keyword (in case we find a use for it in the future). | ||
|
||
# Alternatives | ||
|
||
* Allow private enum variants, as-is today. | ||
* Add a new keyword for `enum` which means "my variants are all private" with | ||
controls to make variants public. | ||
|
||
# Unresolved questions | ||
|
||
* Is the assertion that private enum variants are rarely used true? Are there | ||
legitimate use cases for keeping the `priv` keyword? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(This is meant to be
pub enum Foo
to match the comment, right?)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, thanks!