RFC: Private fields by default

[alexcrichton]

No description provided.

[sfackler]

I'm not sure that the behavior of mixed-privacy tuple structs makes a ton of sense. Mixed-privacy structural structs (is that really the term?) are pretty straightforward since they're inherently unordered, so patterns can ignore the existence of the private fields entirely:

pubstructFoo{a:int,pubb:int,c:int,pubd:int,}letFoo{ref b,ref d, _ } = foo;

It seems like that in the case of tuple structs, the existence and location of a private field has to be part of the public API, which seems like it defeats a lot of the purpose of having private fields:

pubstructFoo(int,pubint,int,pubint);letFoo(_,ref b, _,ref d) = f;

Is there a use case for mixed-privacy tuple structs? One option could be to force all parameters to have the same visibility, but that seems like it would be a bit inconsistent.

[alexcrichton]

That's an interesting point. I would guess that as with structs, most tuple structs will have all-private fields. I would imagine that any all-public tuple structs would benefit from the same syntax of all-public structural structs (yeah, I just kinda made up that term).

This would benefit from the planned .. syntax for struct matching:

pubstructFoo(pubint,int,char);letFoo(first_field, ..) = ...;

In terms of API stability, I think that I will amend this RFC to forbid the following:

pubstructFoo(int);letFoo(_) = ...;

If this were allowed, then you couldn't add fields backwards compatibly. It would only deny pattern matches if all fields were private, however.

[sfackler]

Should the compiler also prevent public fields from appearing after private fields?

[alexcrichton]

I wouldn't expect the compiler to prevent an occurrence such as that. Perhaps some external tool which has extra lints targeted at API stability (not that there's much other than this), but it seems like a valid enough thing to do as part of the language (if a bit silly)

[bill-myers]

An option could to be imitate C++, and have both a "struct" and "class" keywords with different privacy.

My suggestion would be to make "struct" always all-public, make "class" private-by-default, and make a class with all public fields be an error, so that there is exactly one way to express any structure.

It's not clear whether the added complexity of two keywords is worth not having to specify "pub" for all-public fields, but on the other hand C++ programmers are already familiar with that.

In C#, struct and class have a different meaning (in Rust parlance, C# class is an implicit "type Foo = @mut Foo", while C# struct is a Rust Pod struct), so this might generate some confusion for C#-only programmers.

On the other hand, additional syntax sugar might be tied into this, like automatically #deriving stuff for structs but not classes.

Scala is another language with two keywords with different privacy and deriving semantics, which are called "class" and "case class".

[glaebhoerl]

@bill-myers You might be interested in #10 wherein I take a similar tack, albeit with different syntax.

[brson]

Merged as RFC 4: https://github.com/rust-lang/rfcs/blob/master/active/0004-private-fields.md

Meeting discussion: https://github.com/mozilla/rust/wiki/Meeting-weekly-2014-03-25#private-fields-by-defaul

[liigo]

an easy method to make struct fields all public:

// uses a new keyword `full` to ensure that
// all fields in this struct are public, and must be pubic.
pub full struct Point {
x: int,
y: int,
}