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

Projects
None yet
7 participants
@alexcrichton
Member

alexcrichton commented Mar 12, 2014

No description provided.

@sfackler

This comment has been minimized.

Show comment
Hide comment
@sfackler

sfackler Mar 12, 2014

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.

Member

sfackler commented Mar 12, 2014

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

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Mar 12, 2014

Member

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.

Member

alexcrichton commented Mar 12, 2014

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

This comment has been minimized.

Show comment
Hide comment
@sfackler

sfackler Mar 12, 2014

Member

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

Member

sfackler commented Mar 12, 2014

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

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Mar 12, 2014

Member

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)

Member

alexcrichton commented Mar 12, 2014

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 referenced this pull request Mar 13, 2014

Merged

RFC: RFC process redux #6

brson referenced this pull request in brson/rfcs Mar 13, 2014

@jfager

This comment has been minimized.

Show comment
Hide comment
@jfager

jfager Mar 15, 2014

For Baz, does this mean let Baz(foo, bar) = b;, let Baz(foo, _, _, bar) = b; or something else?

jfager commented on active/0000-private-fields.md in 98565f7 Mar 15, 2014

For Baz, does this mean let Baz(foo, bar) = b;, let Baz(foo, _, _, bar) = b; or something else?

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Mar 15, 2014

Owner

The latter, you'd have to explicitly ignore the private fields.

Owner

alexcrichton replied Mar 15, 2014

The latter, you'd have to explicitly ignore the private fields.

@jfager

This comment has been minimized.

Show comment
Hide comment
@jfager

jfager Mar 15, 2014

What does this look like for creating Baz? let b = Baz(foo, bar);? What happens to the private fields, do they get a default value?

jfager commented on active/0000-private-fields.md in 98565f7 Mar 15, 2014

What does this look like for creating Baz? let b = Baz(foo, bar);? What happens to the private fields, do they get a default value?

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Mar 15, 2014

Owner

The struct cannot be created outside of the containing module (similarly to structural private fields)

Owner

alexcrichton replied Mar 15, 2014

The struct cannot be created outside of the containing module (similarly to structural private fields)

@bill-myers

This comment has been minimized.

Show comment
Hide comment
@bill-myers

bill-myers Mar 16, 2014

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".

bill-myers commented Mar 16, 2014

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

This comment has been minimized.

Show comment
Hide comment
@glaebhoerl

glaebhoerl Mar 16, 2014

Contributor

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

Contributor

glaebhoerl commented Mar 16, 2014

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

@brson brson merged commit 98565f7 into rust-lang:master Mar 25, 2014

@liigo

This comment has been minimized.

Show comment
Hide comment
@liigo

liigo Mar 26, 2014

Contributor

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,
}
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 alexcrichton:private-fields branch Jun 18, 2014

aturon pushed a commit that referenced this pull request Dec 18, 2014

Merge pull request #1 from cgaebel/drain
Add drain, and link to WIP implementations.

@mkaufmann mkaufmann referenced this pull request Jan 14, 2015

Merged

Integer overflow #560

aturon added a commit that referenced this pull request Feb 3, 2015

Merge pull request #1 from alexcrichton/pr-1
Mention ChanReader/ChanWriter will be unstable

cesarb pushed a commit to cesarb/rust-rfcs that referenced this pull request Jul 13, 2015

Merge pull request rust-lang#1 from rkjnsn/patch-1
Modify read_full/read_exact RFC

nikomatsakis pushed a commit that referenced this pull request Feb 5, 2016

Merge pull request #1 from aturon/explicate-gates
Add specifics around feature gates

alexcrichton pushed a commit that referenced this pull request Mar 17, 2016

kennytm referenced this pull request in kennytm/rfcs Jun 26, 2016

Merge pull request #1 from killercup/patch-1
Fix some typos in Pi Types RFCs

@durka durka referenced this pull request Aug 2, 2016

Merged

mem::discriminant() #1696

aturon pushed a commit that referenced this pull request Oct 22, 2016

Merge pull request #1 from Havvy/patch-1
Explicit type punning alternative.

@llogiq llogiq referenced this pull request Dec 9, 2016

Closed

Alloca for Rust #1808

@chriskrycho chriskrycho referenced this pull request Dec 30, 2016

Closed

Document all features in the reference #38643

0 of 17 tasks complete

phaazon referenced this pull request in phaazon/rfcs Feb 10, 2017

Merge pull request #1 from Havvy/patch-1
Explicit type punning alternative.

@chriskrycho chriskrycho referenced this pull request Mar 11, 2017

Closed

Document all features #9

18 of 48 tasks complete

withoutboats pushed a commit that referenced this pull request Apr 24, 2017

Merge pull request #1 from durka/patch-9
Update 0000-trait-alias.md

aturon pushed a commit that referenced this pull request Jul 17, 2017

aturon pushed a commit that referenced this pull request Jul 25, 2017

Merge pull request #1 from Ericson2314/extern-types
A lot of misc changes to extern types

@crlf0710 crlf0710 referenced this pull request Jan 23, 2018

Closed

RFC: Inherent traits #2309

aturon pushed a commit that referenced this pull request Jan 27, 2018

Centril added a commit that referenced this pull request Mar 18, 2018

Merge pull request #1 from Centril/patch-const-repeat-1
rfc, const-repeat-expr: notes on is_rvalue_promotable(expr)

@ssokolow ssokolow referenced this pull request May 4, 2018

Closed

RFC: `throw` expressions #2426

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment