-
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
Conversation
|
||
enum Foo { | ||
Bar, | ||
Baz(BazInner) |
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 that this_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 the priv
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 :)
👍 I've only seen private variants used in the second case, and I think wrapping in a struct is fine given how infrequently it comes up. I can't think of any cases of partially-private variant lists off the top of my head, or even any use cases for them. |
+1 |
cc rust-lang/rust#8122, where lots of discussion happened long ago |
// priv Baz, | ||
// } | ||
|
||
enum Foo { |
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!
please keeping the |
@liigo: The |
Merged as RFC 6, tracked by rust-lang/rust#13535 |
…lexcrichton Hi! While researching stuff for the reference and the grammar, I came across a few mentions of using the `priv` keyword that was removed in 0.11.0 (rust-lang#13547, rust-lang#8122, rust-lang/rfcs#26, [RFC 0026](https://github.com/rust-lang/rfcs/blob/master/text/0026-remove-priv.md)). One occurrence is a mention in the reference, a few are in comments, and a few are marking test functions. I left the test that makes sure you can't name an ident `priv` since it's still a reserved keyword. I did a little grepping around for `priv `, priv in backticks, `Private` etc and I think the remaining instances are fine, but if anyone knows anywhere in particular I should check for any other lingering mentions of `priv`, please let me know and I would be happy to! 🍂 🌊
…lexcrichton Hi! While researching stuff for the reference and the grammar, I came across a few mentions of using the `priv` keyword that was removed in 0.11.0 (rust-lang#13547, rust-lang#8122, rust-lang/rfcs#26, [RFC 0026](https://github.com/rust-lang/rfcs/blob/master/text/0026-remove-priv.md)). One occurrence is a mention in the reference, a few are in comments, and a few are marking test functions. I left the test that makes sure you can't name an ident `priv` since it's still a reserved keyword. I did a little grepping around for `priv `, priv in backticks, `Private` etc and I think the remaining instances are fine, but if anyone knows anywhere in particular I should check for any other lingering mentions of `priv`, please let me know and I would be happy to! 🍂 🌊
Copyedit tutorial
No description provided.