Skip to content
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 2 commits into from
Apr 15, 2014
Merged

Conversation

alexcrichton
Copy link
Member

No description provided.


enum Foo {
Bar,
Baz(BazInner)
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

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 :)

@sfackler
Copy link
Member

👍

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.

@bstrie
Copy link
Contributor

bstrie commented Apr 1, 2014

+1
Given that RFC 4 has already been accepted, this seems entirely uncontroversial.

@alexcrichton
Copy link
Member Author

cc rust-lang/rust#8122, where lots of discussion happened long ago

// priv Baz,
// }

enum Foo {
Copy link
Member

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?)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, thanks!

@liigo
Copy link
Contributor

liigo commented Apr 13, 2014

please keeping the priv keyword to explicitly ensure that a field is set private by design, instead of forgetting put pub keyword.

@thestinger
Copy link

@liigo: The priv keyword is no longer allowed on fields. The whole point of making privacy the default was to prevent accidentally exposing private details of the API. There's no harm in accidentally forgetting to mark a field as public because it will be easily caught... the API will not work.

@brson brson merged commit 8c4aedc into rust-lang:master Apr 15, 2014
@brson
Copy link
Contributor

brson commented Apr 15, 2014

Merged as RFC 6, tracked by rust-lang/rust#13535

@alexcrichton alexcrichton deleted the remove-priv branch June 18, 2014 22:27
Manishearth added a commit to Manishearth/rust that referenced this pull request May 1, 2015
…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! 🍂 🌊
Manishearth added a commit to Manishearth/rust that referenced this pull request May 1, 2015
…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! 🍂 🌊
withoutboats pushed a commit to withoutboats/rfcs that referenced this pull request Jan 15, 2017
@Centril Centril added A-privacy Privacy related proposals & ideas A-keyword Proposals relating to keywords. labels Nov 23, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-keyword Proposals relating to keywords. A-privacy Privacy related proposals & ideas
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants