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
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
82 changes: 82 additions & 0 deletions active/0000-remove-priv.md
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 {
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!

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

}

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?