-
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
Merged
Merged
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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, | ||
// } | ||
|
||
pub enum Foo { | ||
Bar, | ||
Baz(BazInner) | ||
} | ||
|
||
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? |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
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 comment
The reason will be displayed to describe this comment to others. Learn more.
No,
BazInner
is a public type, it just can't be instantiated outside this module.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.
Oops, I misread. Why can't
BazInner
be instantiated? I'd think thatthis_module::BazInner(())
would work, right?Even if it can't be instantiated, it still means that
Baz
can be matched against, which is forbidden in thepriv
case.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.
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 comment
The 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 :)