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: Private fields by default #1

Merged
merged 1 commit into from
Mar 25, 2014

Conversation

alexcrichton
Copy link
Member

No description provided.

@sfackler
Copy link
Member

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:

pub struct Foo {
    a: int,
    pub b: int,
    c: int,
    pub d: int,
}

let Foo { 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:

pub struct Foo(int, pub int, int, pub int);

let Foo(_, 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
Copy link
Member Author

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:

pub struct Foo(pub int, int, char);

let Foo(first_field, ..) = ...;

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

pub struct Foo(int);

let Foo(_) = ...;

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
Copy link
Member

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

@alexcrichton
Copy link
Member Author

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)

@pnkfelix pnkfelix mentioned this pull request Mar 13, 2014
brson referenced this pull request in brson/rfcs Mar 13, 2014
@bill-myers
Copy link

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
Copy link
Contributor

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

glaebhoerl referenced this pull request in glaebhoerl/rfcs Mar 17, 2014
@brson brson merged commit 98565f7 into rust-lang:master Mar 25, 2014
@liigo
Copy link
Contributor

liigo commented Mar 26, 2014

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,
}

@alexcrichton alexcrichton deleted the private-fields branch June 18, 2014 22:27
aturon pushed a commit that referenced this pull request Dec 18, 2014
Add drain, and link to WIP implementations.
@mkaufmann mkaufmann mentioned this pull request Jan 14, 2015
aturon added a commit that referenced this pull request Feb 3, 2015
Mention ChanReader/ChanWriter will be unstable
cesarb pushed a commit to cesarb/rust-rfcs that referenced this pull request Jul 13, 2015
Modify read_full/read_exact RFC
nikomatsakis pushed a commit that referenced this pull request Feb 5, 2016
Add specifics around feature gates
alexcrichton pushed a commit that referenced this pull request Mar 17, 2016
This was referenced Jun 7, 2022
@Keavon Keavon mentioned this pull request Jul 19, 2022
Urhengulas pushed a commit to ferrous-systems/rfcs that referenced this pull request May 23, 2023
First attempt to flesh out motivation and guide-level explaination
Mark-Simulacrum pushed a commit that referenced this pull request Jun 15, 2023
…olicy

Clarify that audits evaluate both moderation policies and their application
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-data-types RFCs about data-types A-privacy Privacy related proposals & ideas A-product-types Product type related proposals A-typesystem Type system related proposals & ideas
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants