Removing `priv` as a keyword

[alexcrichton]

Now that you can't really put pub at the top-level of things like impl/extern/trait, you don't need the priv keyword to control method visibility of various items because they're all private by default.

pros:

• I think that this would really simplify public/private because there's one and only one rule: private by default, public if you flag it
• one less keyword!

difficulties:

• Right now this is the only way to make struct fields private. I personally believe that private-by-default for struct fields isn't that bad of an idea, and if this were the only thing blocking removing priv I'd vote to remove it.

cons:

• Enum variants can currently be tagged as priv, and if we removed priv there would be no way to make half the enum variants public and half private. In theory pub enum makes everything public and you could otherwise write pub on each variant, but the type name would still then have to be public and if it didn't have pub in front of it it wouldn't really make sense
• Private-by-default for structs is kind of annoying sometimes.

What do others think about this?

[AndresOsinski]

Well, Haskell exposes members explicitly, as does Node. Java asks for
explicit private/public members, as does C++.

I think there's a good case, not only in language precedent but as a
general good practice, that public members should be explicitly tagged as
such. It also creates a slight amount of mental friction when deciding to
make a member public. IMO, this is good; you actually have to reason at
least a tiny bit when you expose a member, which generally leads to
more succinct and better-designed interfaces (much like immutability forces
you to reason about correctness in a way that mutable-everything does not).

On Tue, Jul 30, 2013 at 4:06 AM, Alex Crichton notifications@github.comwrote:

Now that you can't really put pub at the top-level of things like
impl/extern/trait, you don't need the priv keyword to control method
visibility of various items because they're all private by default.

pros:

• I think that this would really simplify public/private because
  there's one and only one rule: private by default, public if you flag it
• one less keyword!

difficulties:

• Right now this is the only way to make struct fields private. I
  personally believe that private-by-default for struct fields isn't that bad
  of an idea, and if this were the only thing blocking removing priv I'd
  vote to remove it.

cons:

• Enum variants can currently be tagged as priv, and if we removed
  priv there would be no way to make half the enum variants public and half
  private. In theory pub enum makes everything public and you could
  otherwise write pub on each variant, but the type name would still
  then have to be public and if it didn't have pub in front of it it
  wouldn't really make sense
• Private-by-default for structs is kind of annoying sometimes.

What do others think about this?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8122
.

Andrés Osinski
http://www.andresosinski.com.ar/

[Thiez]

I don't think it's possible to pattern match on a struct that has one or more private members. Having to mark almost every struct field as pub just so I can use pattern matching seems much more inconvenient to me than having priv as a keyword.

[bstrie]

I agree that "private by default, always" is a simpler rule, but I caution against overexuberance at the thought of removing a keyword. It very well might not be worth the loss of convenience.

One good data point would be to figure out how many of the currently-public fields in the compiler could actually be private. An off-by-default lint pass might help with this.

[bblum]

I was almost sold on this until I realized this meant you would have to write, for example, pub enum Option<T> { pub Some(T), pub None } in order for anybody else to construct or pattern-match against your enum at all.

[bluss]

Can we change static to priv by default as well?

[alexcrichton]

@bblum: I would be ok with pub enum makes all variants public, while enum implies all variants are private. That's one of the sticky points of removing priv because then you can't have a mixture of public/private enum variants.

@blake2-ppc: I would certainly hope so!

[brson]

I guess I'm in somewhat in favor since I think pub struct fields are the wrong default. I suspect that inheriting visibility from enums to their variants will not work out satisfactorily though - we tried that for impls and found it confusing.

[alexcrichton]

@brson, although isn't that what enums do right now? (inheriting visibility from the type name to the variants).

[emberian]

I don't think private-by-default struct fields are a good thing. You cannot construct them at all without constructor functions, which just makes it more work.

[thestinger]

The fields would be private by-default only, we wouldn't require any more constructor functions than we have now.

[emberian]

Well, yes, but it also requires an explosion of pub, unless we inherit
visibility, but I thought we were going away from that.

Then again, traits already require pub, so maybe it won't be as bad as
I'm imagining it. It would be nice to have a single rule.

On Wed, Jul 31, 2013 at 6:12 PM, Daniel Micay notifications@github.comwrote:

The fields would be private by-default only, we wouldn't require any
more constructor functions.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8122#issuecomment-21899998
.

[thestinger]

I think private-by-default is better because a wrongly private field is going to be quickly noticed. I wouldn't be surprised if we actually had more structs where the fields should be private, than those used as transparent blobs of data.

It's also odd for the fields in newtypes and tuple structs to be public by-default (or only public, as they are right now). You would expect half of their purpose to be concealing an implementation detail, otherwise you would just use a type alias (unless you needed to override a trait implementation).

[emberian]

This is true. After thinking about it some more I'm fine with this.