Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Goffredo Marocchi via swift-evolution]

+1

Sent from my iPhone

> On 13 Apr 2017, at 08:15, Tino Heth via swift-evolution 
>  wrote:
> 
>> No change
>> Benefit: No change to the language.
>> Drawback: Must use “fileprivate” to build up a type through extensions.
>> 
>> SE–0159
>> Benefit: Simplifies the access control model.
>> Drawback: Cannot protect invariants within a file.
>> 
>> SE–0169
>> Benefit: Cross-type sharing is clearly marked.
>> Drawback: Must use a helper type to protect invariants within a file.
>> 
>> Rename
>> Benefit: No change to semantics.
>> Drawback: Two separate keywords are changed.
> 
> 
> As the dedicated thread was highjacked ;-), imho it's just fair to add 
> another option here...
> 
> Nested extensions
> Benefit: Expressive power, no breaking change (and more…)
> Drawback: More indentation
> 
> The table is quite boring:
> Nested Extensions
> Simple file   private
> Extensionsprivate
> Sharing   private
> Helper visibleprivate
> Helper hidden private
> Invariantsprivate
> Multi-typeprivate
> Multi-type + ext  private
> 
> I'm not sure about the colour, but if I wasn't to lazy to edit raw HTML, imho 
> there would a lot of green ;-)
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Tino Heth via swift-evolution]

> No change
> Benefit: No change to the language.
> Drawback: Must use “fileprivate” to build up a type through extensions.
> 
> SE–0159
> Benefit: Simplifies the access control model.
> Drawback: Cannot protect invariants within a file.
> 
> SE–0169
> Benefit: Cross-type sharing is clearly marked.
> Drawback: Must use a helper type to protect invariants within a file.
> 
> Rename
> Benefit: No change to semantics.
> Drawback: Two separate keywords are changed.


As the dedicated thread was highjacked ;-), imho it's just fair to add another 
option here...

Nested extensions
Benefit: Expressive power, no breaking change (and more…)
Drawback: More indentation

The table is quite boring:
Nested Extensions
Simple file private
Extensions  private
Sharing private
Helper visible  private
Helper hidden   private
Invariants  private
Multi-type  private
Multi-type + extprivate

I'm not sure about the colour, but if I wasn't to lazy to edit raw HTML, imho 
there would a lot of green ;-)___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Matthew Johnson via swift-evolution]

> On Apr 12, 2017, at 3:15 PM, Nevin Brackett-Rozinsky via swift-evolution 
>  wrote:
> 
> In order to evaluate this proposal, I created a table of as many relevant 
> scenarios as I could think of, and listed how each of the proposed solutions 
> would work there. The four access level systems I compared are:
> 
> No change: The existing Swift 3 status quo with “fileprivate” and “private”.
> 
> SE–0159: Revert to the Swift 2 meaning of “private” (file visibility) and 
> eliminate scoped access altogether.
> 
> SE–0169: Expand “private” to include the current type and all its extensions 
> in the same file.
> 
> Rename: Change the spelling of “private” to “scoped”, and “fileprivate” to 
> “private”.
> 
> I ended up with a list of eight scenarios to evaluate. These are:
> 
> 1. “Simple file”, a single type with no extensions.
> 2. “Extensions”, a single type and extensions thereof.
> 3. “Sharing”, multiple types that need privileged access to each other.
> 4. “Helper visible”, the interface of a helper (or nested) type for use 
> within the file.
> 5. “Helper hidden”, the details of a helper type that should not be visible 
> to other types.
> 6. “Invariants”, the details of a type that should only be touched by 
> dedicated methods.
> 7. “Multi-type”, multiple types that should not have privileged access to 
> each other.
> 8. “Multi-type + ext”, multiple types that should not have privileged access 
> to each other, and extensions thereof.
> 
> The entries in the table have seven possible values:
> 
> private: The “private” keyword works.
> 
> fileprivate: The “fileprivate” keyword works.
> 
> scoped: The “scoped” keyword works.
> 
> private x2: The “private” keyword works if the types are put into separate 
> files.
> 
> fileprivate x2: The “fileprivate” keyword works if the types are put into 
> separate files.
> 
> helper type: The goal can only be achieved by creating a helper type.
> 
> no hiding: The specified items cannot be hidden from the rest of the file.
> 
> Here is the completed and color-coded table (I hope it displays properly in 
> this email):
> 
> 
> 
> No change
> SE–0159
> SE–0169
> Rename
> Simple file
> private
> private
> private
> private
> Extensions
> fileprivate
> private
> private
> private
> Sharing
> fileprivate
> private
> fileprivate
> private
> Helper visible
> fileprivate
> private
> fileprivate
> private
> Helper hidden
> private
> no hiding
> private
> scoped
> Invariants
> private
> no hiding
> helper type
> scoped
> Multi-type
> private
> private x2
> private
> scoped
> Multi-type + ext
> fileprivate x2
> private x2
> private
> private x2
> 
> 
> Analysis
> 
> Some people have said on-list that they view cross-type sharing as an 
> anti-pattern. If that is true, then we can simply ignore the “Sharing” row 
> because it would not be worth optimizing for. This hardly changes the table 
> though, as that row is identical to the “Helper visible” row below it.
> 
> Regarding the “Invariants” row, note that a helper type can be used for this 
> purpose under “No change” and “Rename” just as well as under “SE–0169”. The 
> difference is that SE-0169 provides no other way to hide invariants from the 
> rest of the type, whereas the other two have an access level suited to the 
> purpose. Similarly, the multi-type rows can be satisfied by separate files 
> regardless of which access system is in place.
> 
> If a person takes the view that things in the same file should naturally have 
> access to one another, then the bottom four rows of the table can be ignored. 
> Such a person might have the mantra, “Only put things together if they belong 
> together”, and they would ask, “What else is in the file that you are trying 
> to hide from?”
> 
> For someone whose primary use-case is to put one type in a file and build it 
> up through extensions, the “Extension” row is of greatest concern. To them, 
> any of SE–0159, SE–0169, or renaming would let them use “private” instead of 
> “fileprivate” everywhere.
> 
> As a final remark, each of the four options has one notable benefit and one 
> notable drawback, not all of which are apparent from the above table:
> 
> No change
> Benefit: No change to the language.
> Drawback: Must use “fileprivate” to build up a type through extensions.
> 
> SE–0159
> Benefit: Simplifies the access control model.
> Drawback: Cannot protect invariants within a file.
> 
> SE–0169
> Benefit: Cross-type sharing is clearly marked.
> Drawback: Must use a helper type to protect invariants within a file.

FWIW, a secondary drawback to SE-0169 is that the protection afforded by this 
helper type is permeable - the helper type can be extended anywhere inside the 
file.  It is more than SE-0159 but not as strong a guarantee as either no 
change or rename.  Extensions to the helper type will stand out much more 
clearly than inadvertent use of a `private` member under SE-0159 but readers 
still need to know they don’t exist or look 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Nevin Brackett-Rozinsky via swift-evolution]

In order to evaluate this proposal, I created a table of as many relevant
scenarios as I could think of, and listed how each of the proposed
solutions would work there. The four access level systems I compared are:

*No change:* The existing Swift 3 *status quo* with “fileprivate” and
“private”.

*SE–0159:* Revert to the Swift 2 meaning of “private” (file visibility) and
eliminate scoped access altogether.

*SE–0169:* Expand “private” to include the current type and all its
extensions in the same file.

*Rename:* Change the spelling of “private” to “scoped”, and “fileprivate”
to “private”.

I ended up with a list of eight scenarios to evaluate. These are:

1. “Simple file”, a single type with no extensions.
2. “Extensions”, a single type and extensions thereof.
3. “Sharing”, multiple types that need privileged access to each other.
4. “Helper visible”, the interface of a helper (or nested) type for use
within the file.
5. “Helper hidden”, the details of a helper type that should not be visible
to other types.
6. “Invariants”, the details of a type that should only be touched by
dedicated methods.
7. “Multi-type”, multiple types that should not have privileged access to
each other.
8. “Multi-type + ext”, multiple types that should not have privileged
access to each other, and extensions thereof.

The entries in the table have seven possible values:

*private:* The “private” keyword works.

*fileprivate:* The “fileprivate” keyword works.

*scoped:* The “scoped” keyword works.

*private x2:* The “private” keyword works if the types are put into
separate files.

*fileprivate x2:* The “fileprivate” keyword works if the types are put into
separate files.

*helper type:* The goal can only be achieved by creating a helper type.

*no hiding:* The specified items cannot be hidden from the rest of the file.

Here is the completed and color-coded table (I hope it displays properly in
this email):



*No change*

*SE–0159*

*SE–0169*

*Rename*

*Simple file*

private

private

private

private

*Extensions*

fileprivate

private

private

private

*Sharing*

fileprivate

private

fileprivate

private

*Helper visible*

fileprivate

private

fileprivate

private

*Helper hidden*

private

no hiding

private

scoped

*Invariants*

private

no hiding

helper type

scoped

*Multi-type*

private

private x2

private

scoped

*Multi-type + ext*

fileprivate x2

private x2

private

private x2


*Analysis*

Some people have said on-list that they view cross-type sharing as an
anti-pattern. If that is true, then we can simply ignore the “Sharing” row
because it would not be worth optimizing for. This hardly changes the table
though, as that row is identical to the “Helper visible” row below it.

Regarding the “Invariants” row, note that a helper type can be used for
this purpose under “No change” and “Rename” just as well as under
“SE–0169”. The difference is that SE-0169 provides no other way to hide
invariants from the rest of the type, whereas the other two have an access
level suited to the purpose. Similarly, the multi-type rows can be
satisfied by separate files regardless of which access system is in place.

If a person takes the view that things in the same file should naturally
have access to one another, then the bottom four rows of the table can be
ignored. Such a person might have the mantra, “Only put things together if
they belong together”, and they would ask, “What else is in the file that
you are trying to hide from?”

For someone whose primary use-case is to put one type in a file and build
it up through extensions, the “Extension” row is of greatest concern. To
them, any of SE–0159, SE–0169, or renaming would let them use “private”
instead of “fileprivate” everywhere.

As a final remark, each of the four options has one notable benefit and one
notable drawback, not all of which are apparent from the above table:

*No change*
Benefit: No change to the language.
Drawback: Must use “fileprivate” to build up a type through extensions.

*SE–0159*
Benefit: Simplifies the access control model.
Drawback: Cannot protect invariants within a file.

*SE–0169*
Benefit: Cross-type sharing is clearly marked.
Drawback: Must use a helper type to protect invariants within a file.

*Rename*
Benefit: No change to semantics.
Drawback: Two separate keywords are changed.

 • • •

And now, having said all that, I need to go take a nap!

Once everything has percolated, I’ll come back to write a review of the
current proposal.

Nevin
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Chris Lattner via swift-evolution]

> On Apr 10, 2017, at 12:28 PM, John McCall via swift-evolution 
>  wrote:
> 
>> Speaking just for myself, I don't think we'd accept such a change purely for 
>> aesthetics;
>> 
>> If I recall correctly, Chris in post-review discussions communicated that a 
>> new keyword to replace `fileprivate` would be considered if `fileprivate` 
>> turned out to be commonly used enough to be aesthetically problematic?
> 
> Yes.  We would consider it.  Chris probably believes that we're more likely 
> to accept that change than I do; that's why I was careful to say that I was 
> just speaking for myself.  (Chris didn't need to say that explicitly in his 
> message because he wasn't explicitly speaking for the Core Team in other 
> parts.)

FWIW, there is a temporal aspect to this.  1-2 weeks ago, I was more open to 
the discussion about renaming fileprivate.  However, as of the core team 
meeting last week, it became clear that the priority of maintaining source 
stability (and thus, not massively thrashing source files in the 3->4 
conversion) is an overriding concern.

As such, it is clear that changing fileprivate isn’t going to happen.  This is 
the direct sequence of events that led to 0169 being proposed.

-Chris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Vladimir.S via swift-evolution]

On 11.04.2017 19:47, Jose Cheyo Jimenez via swift-evolution wrote:


On Apr 6, 2017, at 4:25 PM, Slava Pestov via swift-evolution 
> wrote:


Strong -1. This is a source breaking change, but Swift 4 stage 2 is already 
over.


I agree with you here. I don't think the proposal will be accepted as is, because of 
the breaking change.


What if there was a way to make this a new feature so it is not a breaking 
change?

I can see this same proposal being accepted if it was revised to mark the new 
extension behavior explicitly.


I like this idea, only extensions explicitly marked as "privileged" can have access 
to private members of the type.
But I suggest then go forward and do not use extension to access the private members 
but instead introduce new construction, which also can have stored properties and 
will have access modifier rules for types (not the rules for extensions). And such 
construction will be treated as continued declaration of the type itself. Only in the 
same file for now.


For example (just as idea for discussion) :

struct A {
  private var x = 0
}

continue A: P1 {
  private var y = 10
  func foo() {print(x + y)}
}

continue A: P2 {
  func bar() {print(x + y)}
}

Probably such type also should be marked somehow to be allowed to have continued 
definition, like


struct A split {
}

Later, when we'll have submodules, such 'continue' construction for the type should 
be allowed in other files of the same submodule and provide the flexible way to 
define the same type in a number of files.




*Type.swift*
*
*
struct A {
private func foo() {}
}

*partial* extension A {  // any other keyword would do here or even \
func baz() {
foo()  // okay
}
}

extension A {
func boo() {
foo()  // error. Same as swift 3.
}
}

*Other.swift*
*
*
*partial* extension A {  // error. Partial extensions only allowed within the 
declaring file.

}

extension A {
func boo() {
foo()  // error. Same as swift 3.
}
}





Slava

On Apr 6, 2017, at 4:10 PM, Douglas Gregor > wrote:


Hello Swift community,

The review of SE-0169 "Improve Interaction Between private Declarations and 
Extensions" begins now and runs through April 11, 2017. The proposal is available 
here:



https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md

Reviews are an important part of the Swift evolution process. All reviews should 
be sent to the swift-evolution mailing list at


https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review 
manager. When replying, please try to keep the proposal link at the top of the 
message:


Proposal link:


https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md

Reply text

Other replies


  
What
  goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your review:


  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to 
Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do
you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or 
an
in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Doug

Review Manager

___
swift-evolution-announce mailing list
swift-evolution-annou...@swift.org 
https://lists.swift.org/mailman/listinfo/swift-evolution-announce


___
swift-evolution mailing list
swift-evolution@swift.org 
https://lists.swift.org/mailman/listinfo/swift-evolution




___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Jose Cheyo Jimenez via swift-evolution]

> On Apr 6, 2017, at 4:25 PM, Slava Pestov via swift-evolution 
>  wrote:
> 
> Strong -1. This is a source breaking change, but Swift 4 stage 2 is already 
> over.

I agree with you here. I don't think the proposal will be accepted as is, 
because of the breaking change. 

What if there was a way to make this a new feature so it is not a breaking 
change?

I can see this same proposal being accepted if it was revised to mark the new 
extension behavior explicitly.

Type.swift

struct A { 
private func foo() {}
}

*partial* extension A {  // any other keyword would do here or even \
func baz() {
foo()  // okay 
}
}

extension A {
func boo() {
foo()  // error. Same as swift 3.
}
}

Other.swift

*partial* extension A {  // error. Partial extensions only allowed within the 
declaring file. 
}

extension A {
func boo() {
foo()  // error. Same as swift 3.
}
}



> 
> Slava
> 
>> On Apr 6, 2017, at 4:10 PM, Douglas Gregor > > wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0169 "Improve Interaction Between private Declarations and 
>> Extensions" begins now and runs through April 11, 2017. The proposal is 
>> available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
>>  
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager. When replying, please try to keep the proposal link at the top of 
>> the message:
>> 
>> Proposal link:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
>>  
>> 
>> Reply text
>> Other replies
>>  
>> What
>>  goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. When writing your review, here are some questions you might want to 
>> answer in your review:
>> 
>> What is your evaluation of the proposal?
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
>> Does this proposal fit well with the feel and direction of Swift?
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
>> More information about the Swift evolution process is available at
>> 
>> https://github.com/apple/swift-evolution/blob/master/process.md 
>> 
>> Thank you,
>> 
>> -Doug
>> 
>> Review Manager
>> 
>> ___
>> swift-evolution-announce mailing list
>> swift-evolution-annou...@swift.org 
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce 
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[John McCall via swift-evolution]

> On Apr 8, 2017, at 4:12 PM, Xiaodi Wu  wrote:
> 
> On Fri, Apr 7, 2017 at 11:34 PM, John McCall via swift-evolution 
> > wrote:
> 
> > On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution 
> > > wrote:
> >
> > > What is your evaluation of the proposal?
> >
> > If this is the last option we have to change the status quo, any renaming 
> > is off the table, no further changes after Swift 4, and it's either this or 
> > being stuck with 'fileprivate' until the end of time, then +1 from me. It 
> > will increase the convenience of access control for people like me who see 
> > types and their extensions as parts of the same entity, just spread 
> > visually across neighboring blocks. In almost any other language these two 
> > would indeed be one entity, since most languages don't have any way of 
> > dividing types into pieces this way.
> >
> > However, IMHO any of these would be a better solution:
> 
> I'd like to respond briefly to this to clarify the Core Team's decisions 
> about what solutions are under consideration, both now and in the future.  By 
> doing this, I don't mean to pressure you towards any particular stance.  The 
> Core Team asked for this to be proposed because we wanted to know how the 
> community felt about it; we are not specifically trying to get it approved, 
> at least as a group.
> 
> > 1) Rename 'private' to something else ('scoped'?) and rename 'fileprivate' 
> > back to 'private'
> 
> The Core Team has rejected making such a major change in the interpretation 
> of 'private'.  'private' will be tied to scopes, now and forever.  The only 
> question is whether extensions of the same type within a file should be 
> considered part of the same scope for the purposes of 'private'.  Swift 4 is 
> the deadline for making that change; if it, too, is rejected, 'private' will 
> be purely lexical forever.
> 
> > 2) Rename 'fileprivate' to something more friendly (I liked the 'local' 
> > suggestion that Vladimir made today)
> 
> The Core Team is willing to consider adding a new keyword to replace 
> 'fileprivate', but not in Swift 4.
> 
> Speaking just for myself, I don't think we'd accept such a change purely for 
> aesthetics;
> 
> If I recall correctly, Chris in post-review discussions communicated that a 
> new keyword to replace `fileprivate` would be considered if `fileprivate` 
> turned out to be commonly used enough to be aesthetically problematic?

Yes.  We would consider it.  Chris probably believes that we're more likely to 
accept that change than I do; that's why I was careful to say that I was just 
speaking for myself.  (Chris didn't need to say that explicitly in his message 
because he wasn't explicitly speaking for the Core Team in other parts.)

> I bring this up because, in replying to BJ Homer, it occurs to me that there 
> is an interesting solution. If--as I understand--successive access modifiers 
> being supersets of preceding ones is a non-negotiable part of the design, 
> then type-based access modifiers cannot be accommodated in Swift because of 
> the existence of extensions. Ergo, the word "protected" cannot ever be used 
> to mean what it does in C++, etc. It is a perfectly nice word that by its 
> dictionary meaning is plausibly intermediate between "private" and 
> "internal," which we can repurpose to mean protected by the end of file! By 
> co-opting this word, it has the key virtue of definitively demonstrating that 
> Swift cannot and will not support access modifiers that are tied to types.

I wouldn't say that successive access modifiers being supersets of existing 
ones is a part of the design.  We've been reluctant to change *existing* 
modifiers in ways that aren't just weakening them, but that's different.

That said, "protected" is a pretty valuable keyword, and there have been 
several other interesting proposals for it, especially for things that lie on 
the other side of "internal".  I wouldn't want to burn "protected" until we've 
gotten a complete enough picture of what access problems library developers are 
having that we're sure it's not more useful there.

John.


> 
> it would have to be because 'fileprivate' seemed inappropriate for some new 
> generalization, e.g. if we added sub-file submodules and wanted 'fileprivate' 
> to allow access only within the submodule.  That is assuming a lot about how 
> a future submodule feature would work, and we aren't going to design that 
> feature specifically with a goal of replacing this keyword, and frankly we 
> don't know when we're going to take that on at all.  I would caution people 
> against assuming that 'fileprivate' will be renamed.
> 
> > 3) Postpone this until we add submodules, but with the assumption that it 
> > will be possible to make some source-breaking changes at that point
> 
> The Core Team is not willing to change 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Howard Lovatt via swift-evolution]

Review of SE-0169 "Improve Interaction Between private Declarations and 
Extensions" 

What is your evaluation of the proposal?
Yes. Would prefer Swift 2 model but given that that is rejected this is a good 
compromise. 

Is the problem being addressed significant enough to warrant a change to Swift?
Debatable. I have got used to fileprivate (I don't bother with private!)

Does this proposal fit well with the feel and direction of Swift?
Yes. Extensions are needed/preferred in many cases in Swift. 

If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
Yes Scala has fine grained privacy. However I don't use the facilities much in 
practice, preferring to extend visibility beyond the strict minimum for the 
sake of simplicity. 

How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
Not a lot. Quick read. 

-- Howard.

> On 7 Apr 2017, at 9:10 am, Douglas Gregor  wrote:
> 
> The review of SE-0169 "Improve Interaction Between private Declarations and 
> Extensions" begins now and runs through April 11, 2017. The proposal is 
> available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
> Reply text
> Other replies
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Brandon Knope via swift-evolution]

If a lot of people (core team included) agree that the current design is less 
than ideal...why lock in something so important that can never be changed going 
forward?

Why not get it right and force something source breaking that would improve the 
language for everyone going forward?

The language is still, after all, very young. 

I understand the problem it would cause but this isn't like breaking everyone's 
code 10 years later. It's still a fresh language

I'm probably missing some of the complexity and politics behind doing something 
like this, but it just seems like doing the right thing is more beneficial in 
the long run

Brandon 

> On Apr 8, 2017, at 12:34 AM, John McCall via swift-evolution 
>  wrote:
> 
> 
>>> On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution 
>>>  wrote:
>>> 
>>> What is your evaluation of the proposal?
>> 
>> If this is the last option we have to change the status quo, any renaming is 
>> off the table, no further changes after Swift 4, and it's either this or 
>> being stuck with 'fileprivate' until the end of time, then +1 from me. It 
>> will increase the convenience of access control for people like me who see 
>> types and their extensions as parts of the same entity, just spread visually 
>> across neighboring blocks. In almost any other language these two would 
>> indeed be one entity, since most languages don't have any way of dividing 
>> types into pieces this way.
>> 
>> However, IMHO any of these would be a better solution:
> 
> I'd like to respond briefly to this to clarify the Core Team's decisions 
> about what solutions are under consideration, both now and in the future.  By 
> doing this, I don't mean to pressure you towards any particular stance.  The 
> Core Team asked for this to be proposed because we wanted to know how the 
> community felt about it; we are not specifically trying to get it approved, 
> at least as a group.
> 
>> 1) Rename 'private' to something else ('scoped'?) and rename 'fileprivate' 
>> back to 'private'
> 
> The Core Team has rejected making such a major change in the interpretation 
> of 'private'.  'private' will be tied to scopes, now and forever.  The only 
> question is whether extensions of the same type within a file should be 
> considered part of the same scope for the purposes of 'private'.  Swift 4 is 
> the deadline for making that change; if it, too, is rejected, 'private' will 
> be purely lexical forever.
> 
>> 2) Rename 'fileprivate' to something more friendly (I liked the 'local' 
>> suggestion that Vladimir made today)
> 
> The Core Team is willing to consider adding a new keyword to replace 
> 'fileprivate', but not in Swift 4.
> 
> Speaking just for myself, I don't think we'd accept such a change purely for 
> aesthetics; it would have to be because 'fileprivate' seemed inappropriate 
> for some new generalization, e.g. if we added sub-file submodules and wanted 
> 'fileprivate' to allow access only within the submodule.  That is assuming a 
> lot about how a future submodule feature would work, and we aren't going to 
> design that feature specifically with a goal of replacing this keyword, and 
> frankly we don't know when we're going to take that on at all.  I would 
> caution people against assuming that 'fileprivate' will be renamed.
> 
>> 3) Postpone this until we add submodules, but with the assumption that it 
>> will be possible to make some source-breaking changes at that point
> 
> The Core Team is not willing to change the basic design of 'private' in 
> future releases of Swift.  If some feature — perhaps submodules — demands 
> that we define its interaction with 'private', the design of that interaction 
> will have to feel natural and consistent with the at-that-point extant design 
> of 'private'.  For example, it would not be acceptable if, say, adding a 
> submodule declaration to a file suddenly changed the interpretation of 
> 'private'.
> 
> An option (4) that you didn't list but which I should cover for completeness 
> would be to add new keywords in the future with new interpretations.  This is 
> something that the Core Team is willing to consider.  However, speaking just 
> for myself again, I find it unlikely that we would add new access control 
> features just to express increasingly-precise refinements; it would have to 
> be something that felt necessary because of some real inadequacy in the 
> existing access-control levels as applied to some other new feature (e.g. 
> submodules).
> 
> John.
> 
>> The thing I don't like about this proposal (or status quo) - apart from the 
>> fact that it will make people who like the current strict private unhappy - 
>> is that 'private' even right now means kind of two different things:
>> 
>> - for a property or a method defined in a class/struct, it means "available 
>> only inside this type"
>> - for a private global variable/constant/function, or a private type or 
>> 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Xiaodi Wu via swift-evolution]

On Fri, Apr 7, 2017 at 11:34 PM, John McCall via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > > What is your evaluation of the proposal?
> >
> > If this is the last option we have to change the status quo, any
> renaming is off the table, no further changes after Swift 4, and it's
> either this or being stuck with 'fileprivate' until the end of time, then
> +1 from me. It will increase the convenience of access control for people
> like me who see types and their extensions as parts of the same entity,
> just spread visually across neighboring blocks. In almost any other
> language these two would indeed be one entity, since most languages don't
> have any way of dividing types into pieces this way.
> >
> > However, IMHO any of these would be a better solution:
>
> I'd like to respond briefly to this to clarify the Core Team's decisions
> about what solutions are under consideration, both now and in the future.
> By doing this, I don't mean to pressure you towards any particular stance.
> The Core Team asked for this to be proposed because we wanted to know how
> the community felt about it; we are not specifically trying to get it
> approved, at least as a group.
>
> > 1) Rename 'private' to something else ('scoped'?) and rename
> 'fileprivate' back to 'private'
>
> The Core Team has rejected making such a major change in the
> interpretation of 'private'.  'private' will be tied to scopes, now and
> forever.  The only question is whether extensions of the same type within a
> file should be considered part of the same scope for the purposes of
> 'private'.  Swift 4 is the deadline for making that change; if it, too, is
> rejected, 'private' will be purely lexical forever.
>
> > 2) Rename 'fileprivate' to something more friendly (I liked the 'local'
> suggestion that Vladimir made today)
>
> The Core Team is willing to consider adding a new keyword to replace
> 'fileprivate', but not in Swift 4.
>
> Speaking just for myself, I don't think we'd accept such a change purely
> for aesthetics;


If I recall correctly, Chris in post-review discussions communicated that a
new keyword to replace `fileprivate` would be considered if `fileprivate`
turned out to be commonly used enough to be aesthetically problematic?

I bring this up because, in replying to BJ Homer, it occurs to me that
there is an interesting solution. If--as I understand--successive access
modifiers being supersets of preceding ones is a non-negotiable part of the
design, then type-based access modifiers cannot be accommodated in Swift
because of the existence of extensions. Ergo, the word "protected" cannot
ever be used to mean what it does in C++, etc. It is a perfectly nice word
that by its dictionary meaning is plausibly intermediate between "private"
and "internal," which we can repurpose to mean protected by the end of
file! By co-opting this word, it has the key virtue of definitively
demonstrating that Swift cannot and will not support access modifiers that
are tied to types.

it would have to be because 'fileprivate' seemed inappropriate for some new
> generalization, e.g. if we added sub-file submodules and wanted
> 'fileprivate' to allow access only within the submodule.  That is assuming
> a lot about how a future submodule feature would work, and we aren't going
> to design that feature specifically with a goal of replacing this keyword,
> and frankly we don't know when we're going to take that on at all.  I would
> caution people against assuming that 'fileprivate' will be renamed.
>
> > 3) Postpone this until we add submodules, but with the assumption that
> it will be possible to make some source-breaking changes at that point
>
> The Core Team is not willing to change the basic design of 'private' in
> future releases of Swift.  If some feature — perhaps submodules — demands
> that we define its interaction with 'private', the design of that
> interaction will have to feel natural and consistent with the at-that-point
> extant design of 'private'.  For example, it would not be acceptable if,
> say, adding a submodule declaration to a file suddenly changed the
> interpretation of 'private'.
>
> An option (4) that you didn't list but which I should cover for
> completeness would be to add new keywords in the future with new
> interpretations.  This is something that the Core Team is willing to
> consider.  However, speaking just for myself again, I find it unlikely that
> we would add new access control features just to express
> increasingly-precise refinements; it would have to be something that felt
> necessary because of some real inadequacy in the existing access-control
> levels as applied to some other new feature (e.g. submodules).
>
> John.
>
> > The thing I don't like about this proposal (or status quo) - apart from
> the fact that it will make people who like the current strict private
> unhappy - is 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Xiaodi Wu via swift-evolution]

On Sat, Apr 8, 2017 at 12:01 AM, BJ Homer via swift-evolution <
swift-evolution@swift.org> wrote:

> If private is required to be tied to types forever and always, then yes,
> this proposal should be accepted.


Let's be clear: private is not and will never be tied to types. It is tied
to *scopes*. This proposal has received a lot of responses suggesting that
the proposed rules should be extended to allow extensions in the same
module to access private members, but that fundamentally misunderstands
access modifiers in Swift.

Two things here. First, Swift allows types to be extended after the fact:
outside the same declaration, outside the same file, even outside the same
module. Second, Swift has access modifiers where each level of access is a
superset of the previous. That is, if you change `private let a` to
`fileprivate let a`, there is no place where `a` becomes no longer
accessible; the same goes for each pair of access modifiers. These two
design decisions are, as far as I'm aware, "now and forever" aspects of
Swift.

Given that these two things are true, *no access modifier is or can be tied
to types*. This proposal is about extending the meaning of *scope* to
include same-file extensions. If you try to think of private as a
type-private modifier, you will invariably conclude that it is broken,
because you can't see private members in extensions outside the same scope.
You will also see the proposed private as broken, only less so, because you
can't see private members in extensions outside the same file. However,
unless I'm greatly mistaken, it is not the intention of this or any other
proposal to create an access level tied to types.

To do otherwise is to suggest that the use of "private" by beginners and
> the use of same-file extensions by beginners are incompatible. The former
> is silly; "private" is what beginners will naturally reach for. The latter
> is possible, but historically the use of same-file extensions has been
> quite idiomatic. So, I reluctantly agree we should accept this proposal.
>
> -BJ
>
> > On Apr 7, 2017, at 10:34 PM, John McCall via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> >>> On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>>
> >>> What is your evaluation of the proposal?
> >>
> >> If this is the last option we have to change the status quo, any
> renaming is off the table, no further changes after Swift 4, and it's
> either this or being stuck with 'fileprivate' until the end of time, then
> +1 from me. It will increase the convenience of access control for people
> like me who see types and their extensions as parts of the same entity,
> just spread visually across neighboring blocks. In almost any other
> language these two would indeed be one entity, since most languages don't
> have any way of dividing types into pieces this way.
> >>
> >> However, IMHO any of these would be a better solution:
> >
> > I'd like to respond briefly to this to clarify the Core Team's decisions
> about what solutions are under consideration, both now and in the future.
> By doing this, I don't mean to pressure you towards any particular stance.
> The Core Team asked for this to be proposed because we wanted to know how
> the community felt about it; we are not specifically trying to get it
> approved, at least as a group.
> >
> >> 1) Rename 'private' to something else ('scoped'?) and rename
> 'fileprivate' back to 'private'
> >
> > The Core Team has rejected making such a major change in the
> interpretation of 'private'.  'private' will be tied to scopes, now and
> forever.  The only question is whether extensions of the same type within a
> file should be considered part of the same scope for the purposes of
> 'private'.  Swift 4 is the deadline for making that change; if it, too, is
> rejected, 'private' will be purely lexical forever.
> >
> >> 2) Rename 'fileprivate' to something more friendly (I liked the 'local'
> suggestion that Vladimir made today)
> >
> > The Core Team is willing to consider adding a new keyword to replace
> 'fileprivate', but not in Swift 4.
> >
> > Speaking just for myself, I don't think we'd accept such a change purely
> for aesthetics; it would have to be because 'fileprivate' seemed
> inappropriate for some new generalization, e.g. if we added sub-file
> submodules and wanted 'fileprivate' to allow access only within the
> submodule.  That is assuming a lot about how a future submodule feature
> would work, and we aren't going to design that feature specifically with a
> goal of replacing this keyword, and frankly we don't know when we're going
> to take that on at all.  I would caution people against assuming that
> 'fileprivate' will be renamed.
> >
> >> 3) Postpone this until we add submodules, but with the assumption that
> it will be possible to make some source-breaking changes at that point
> >
> > The Core Team is not willing to change the basic design of 'private' in
> 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Jean-Daniel via swift-evolution]

So, +1 for me too. 

I’m part of the people who didn’t want SE-0025 in the first place, and don’t 
like any workaround we try to implement to mitigate it, but taking the Core 
Team decision in account, I feel this is the right thing to do now.

If strong scoped variables are needed, it will always be possible to 
reintroduce them using a new keyword (I will personally be against such 
proposal, but it is a possibility).


> Le 8 avr. 2017 à 06:34, John McCall via swift-evolution 
>  a écrit :
> 
>> 
>> On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution 
>> > wrote:
>> 
>>> What is your evaluation of the proposal?
>> 
>> If this is the last option we have to change the status quo, any renaming is 
>> off the table, no further changes after Swift 4, and it's either this or 
>> being stuck with 'fileprivate' until the end of time, then +1 from me. It 
>> will increase the convenience of access control for people like me who see 
>> types and their extensions as parts of the same entity, just spread visually 
>> across neighboring blocks. In almost any other language these two would 
>> indeed be one entity, since most languages don't have any way of dividing 
>> types into pieces this way.
>> 
>> However, IMHO any of these would be a better solution:
> 
> I'd like to respond briefly to this to clarify the Core Team's decisions 
> about what solutions are under consideration, both now and in the future.  By 
> doing this, I don't mean to pressure you towards any particular stance.  The 
> Core Team asked for this to be proposed because we wanted to know how the 
> community felt about it; we are not specifically trying to get it approved, 
> at least as a group.
> 
>> 1) Rename 'private' to something else ('scoped'?) and rename 'fileprivate' 
>> back to 'private'
> 
> The Core Team has rejected making such a major change in the interpretation 
> of 'private'.  'private' will be tied to scopes, now and forever.  The only 
> question is whether extensions of the same type within a file should be 
> considered part of the same scope for the purposes of 'private'.  Swift 4 is 
> the deadline for making that change; if it, too, is rejected, 'private' will 
> be purely lexical forever.
> 
>> 2) Rename 'fileprivate' to something more friendly (I liked the 'local' 
>> suggestion that Vladimir made today)
> 
> The Core Team is willing to consider adding a new keyword to replace 
> 'fileprivate', but not in Swift 4.
> 
> Speaking just for myself, I don't think we'd accept such a change purely for 
> aesthetics; it would have to be because 'fileprivate' seemed inappropriate 
> for some new generalization, e.g. if we added sub-file submodules and wanted 
> 'fileprivate' to allow access only within the submodule.  That is assuming a 
> lot about how a future submodule feature would work, and we aren't going to 
> design that feature specifically with a goal of replacing this keyword, and 
> frankly we don't know when we're going to take that on at all.  I would 
> caution people against assuming that 'fileprivate' will be renamed.
> 
>> 3) Postpone this until we add submodules, but with the assumption that it 
>> will be possible to make some source-breaking changes at that point
> 
> The Core Team is not willing to change the basic design of 'private' in 
> future releases of Swift.  If some feature — perhaps submodules — demands 
> that we define its interaction with 'private', the design of that interaction 
> will have to feel natural and consistent with the at-that-point extant design 
> of 'private'.  For example, it would not be acceptable if, say, adding a 
> submodule declaration to a file suddenly changed the interpretation of 
> 'private'.
> 
> An option (4) that you didn't list but which I should cover for completeness 
> would be to add new keywords in the future with new interpretations.  This is 
> something that the Core Team is willing to consider.  However, speaking just 
> for myself again, I find it unlikely that we would add new access control 
> features just to express increasingly-precise refinements; it would have to 
> be something that felt necessary because of some real inadequacy in the 
> existing access-control levels as applied to some other new feature (e.g. 
> submodules).
> 
> John.
> 
>> The thing I don't like about this proposal (or status quo) - apart from the 
>> fact that it will make people who like the current strict private unhappy - 
>> is that 'private' even right now means kind of two different things:
>> 
>> - for a property or a method defined in a class/struct, it means "available 
>> only inside this type"
>> - for a private global variable/constant/function, or a private type or 
>> extension, it means "available in this file" i.e. the same as 'fileprivate'
>> 
>> So if we're worried that this proposal makes the meaning of 'private' 
>> unclear - it already is unclear. 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Jakub Suder via swift-evolution]

Fair enough - in this case, definitely +1 on the current proposal.

Kuba

On 8 April 2017 at 06:34, John McCall  wrote:

>
> > On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > > What is your evaluation of the proposal?
> >
> > If this is the last option we have to change the status quo, any
> renaming is off the table, no further changes after Swift 4, and it's
> either this or being stuck with 'fileprivate' until the end of time, then
> +1 from me. It will increase the convenience of access control for people
> like me who see types and their extensions as parts of the same entity,
> just spread visually across neighboring blocks. In almost any other
> language these two would indeed be one entity, since most languages don't
> have any way of dividing types into pieces this way.
> >
> > However, IMHO any of these would be a better solution:
>
> I'd like to respond briefly to this to clarify the Core Team's decisions
> about what solutions are under consideration, both now and in the future.
> By doing this, I don't mean to pressure you towards any particular stance.
> The Core Team asked for this to be proposed because we wanted to know how
> the community felt about it; we are not specifically trying to get it
> approved, at least as a group.
>
> > 1) Rename 'private' to something else ('scoped'?) and rename
> 'fileprivate' back to 'private'
>
> The Core Team has rejected making such a major change in the
> interpretation of 'private'.  'private' will be tied to scopes, now and
> forever.  The only question is whether extensions of the same type within a
> file should be considered part of the same scope for the purposes of
> 'private'.  Swift 4 is the deadline for making that change; if it, too, is
> rejected, 'private' will be purely lexical forever.
>
> > 2) Rename 'fileprivate' to something more friendly (I liked the 'local'
> suggestion that Vladimir made today)
>
> The Core Team is willing to consider adding a new keyword to replace
> 'fileprivate', but not in Swift 4.
>
> Speaking just for myself, I don't think we'd accept such a change purely
> for aesthetics; it would have to be because 'fileprivate' seemed
> inappropriate for some new generalization, e.g. if we added sub-file
> submodules and wanted 'fileprivate' to allow access only within the
> submodule.  That is assuming a lot about how a future submodule feature
> would work, and we aren't going to design that feature specifically with a
> goal of replacing this keyword, and frankly we don't know when we're going
> to take that on at all.  I would caution people against assuming that
> 'fileprivate' will be renamed.
>
> > 3) Postpone this until we add submodules, but with the assumption that
> it will be possible to make some source-breaking changes at that point
>
> The Core Team is not willing to change the basic design of 'private' in
> future releases of Swift.  If some feature — perhaps submodules — demands
> that we define its interaction with 'private', the design of that
> interaction will have to feel natural and consistent with the at-that-point
> extant design of 'private'.  For example, it would not be acceptable if,
> say, adding a submodule declaration to a file suddenly changed the
> interpretation of 'private'.
>
> An option (4) that you didn't list but which I should cover for
> completeness would be to add new keywords in the future with new
> interpretations.  This is something that the Core Team is willing to
> consider.  However, speaking just for myself again, I find it unlikely that
> we would add new access control features just to express
> increasingly-precise refinements; it would have to be something that felt
> necessary because of some real inadequacy in the existing access-control
> levels as applied to some other new feature (e.g. submodules).
>
> John.
>
> > The thing I don't like about this proposal (or status quo) - apart from
> the fact that it will make people who like the current strict private
> unhappy - is that 'private' even right now means kind of two different
> things:
> >
> > - for a property or a method defined in a class/struct, it means
> "available only inside this type"
> > - for a private global variable/constant/function, or a private type or
> extension, it means "available in this file" i.e. the same as 'fileprivate'
> >
> > So if we're worried that this proposal makes the meaning of 'private'
> unclear - it already is unclear. Wouldn't it be much more clear if private
> global variables, functions and classes were required to use the access
> level that means "available in this file", since that's how they actually
> work? (as long as this level is not named 'fileprivate' :)
> >
> > And the other access level, the "available only inside this type"
> (private / scoped), could only be used for things that are actually
> contained inside a type, and wouldn't have two different meanings depending
> on whether 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Rod Brown via swift-evolution]

> On 8 Apr 2017, at 2:34 pm, John McCall via swift-evolution 
>  wrote:
> 
>> 
>> On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution 
>> > wrote:
>> 
>>> What is your evaluation of the proposal?
>> 
>> If this is the last option we have to change the status quo, any renaming is 
>> off the table, no further changes after Swift 4, and it's either this or 
>> being stuck with 'fileprivate' until the end of time, then +1 from me. It 
>> will increase the convenience of access control for people like me who see 
>> types and their extensions as parts of the same entity, just spread visually 
>> across neighboring blocks. In almost any other language these two would 
>> indeed be one entity, since most languages don't have any way of dividing 
>> types into pieces this way.
>> 
>> However, IMHO any of these would be a better solution:
> 
> I'd like to respond briefly to this to clarify the Core Team's decisions 
> about what solutions are under consideration, both now and in the future.  By 
> doing this, I don't mean to pressure you towards any particular stance.  The 
> Core Team asked for this to be proposed because we wanted to know how the 
> community felt about it; we are not specifically trying to get it approved, 
> at least as a group.
> 
>> 1) Rename 'private' to something else ('scoped'?) and rename 'fileprivate' 
>> back to 'private'
> 
> The Core Team has rejected making such a major change in the interpretation 
> of 'private'.  'private' will be tied to scopes, now and forever.  The only 
> question is whether extensions of the same type within a file should be 
> considered part of the same scope for the purposes of 'private'.  Swift 4 is 
> the deadline for making that change; if it, too, is rejected, 'private' will 
> be purely lexical forever.

With this being the case, I want to revise my response to +1. It allows the 
flexibility required for the extension-rich architecture Swift open adopts with 
protocol conformance and I think that’s a good thing, personally.

> 
>> 2) Rename 'fileprivate' to something more friendly (I liked the 'local' 
>> suggestion that Vladimir made today)
> 
> The Core Team is willing to consider adding a new keyword to replace 
> 'fileprivate', but not in Swift 4.
> 
> Speaking just for myself, I don't think we'd accept such a change purely for 
> aesthetics; it would have to be because 'fileprivate' seemed inappropriate 
> for some new generalization, e.g. if we added sub-file submodules and wanted 
> 'fileprivate' to allow access only within the submodule.  That is assuming a 
> lot about how a future submodule feature would work, and we aren't going to 
> design that feature specifically with a goal of replacing this keyword, and 
> frankly we don't know when we're going to take that on at all.  I would 
> caution people against assuming that 'fileprivate' will be renamed.
> 
>> 3) Postpone this until we add submodules, but with the assumption that it 
>> will be possible to make some source-breaking changes at that point
> 
> The Core Team is not willing to change the basic design of 'private' in 
> future releases of Swift.  If some feature — perhaps submodules — demands 
> that we define its interaction with 'private', the design of that interaction 
> will have to feel natural and consistent with the at-that-point extant design 
> of 'private'.  For example, it would not be acceptable if, say, adding a 
> submodule declaration to a file suddenly changed the interpretation of 
> 'private'.
> 
> An option (4) that you didn't list but which I should cover for completeness 
> would be to add new keywords in the future with new interpretations.  This is 
> something that the Core Team is willing to consider.  However, speaking just 
> for myself again, I find it unlikely that we would add new access control 
> features just to express increasingly-precise refinements; it would have to 
> be something that felt necessary because of some real inadequacy in the 
> existing access-control levels as applied to some other new feature (e.g. 
> submodules).
> 
> John.
> 
>> The thing I don't like about this proposal (or status quo) - apart from the 
>> fact that it will make people who like the current strict private unhappy - 
>> is that 'private' even right now means kind of two different things:
>> 
>> - for a property or a method defined in a class/struct, it means "available 
>> only inside this type"
>> - for a private global variable/constant/function, or a private type or 
>> extension, it means "available in this file" i.e. the same as 'fileprivate'
>> 
>> So if we're worried that this proposal makes the meaning of 'private' 
>> unclear - it already is unclear. Wouldn't it be much more clear if private 
>> global variables, functions and classes were required to use the access 
>> level that means "available in this file", since that's how they actually 
>> work? 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Riley Testut via swift-evolution]

> The Core Team has rejected making such a major change in the interpretation 
> of 'private'.  'private' will be tied to scopes, now and forever.  The only 
> question is whether extensions of the same type within a file should be 
> considered part of the same scope for the purposes of 'private'.  Swift 4 is 
> the deadline for making that change; if it, too, is rejected, 'private' will 
> be purely lexical forever.

If private really is tied to scopes now and forever, I certainly have no doubt 
these change should be accepted to alleviate the biggest annoyance with it.

Should this be accepted, to me, using "fileprivate" serves as a flag that 
another type has privileged access to another type's private members. 
Unfortunately, because fileprivate is needed for extensions of the same type, 
then the keyword loses this meaning. If I choose to use extensions to define a 
type (as was a practice greatly encouraged in Swift 1/2), fileprivate serves no 
self-documentation role beyond "private".

Additionally, I truly believe this proposal would align the access control with 
what newcomers to the language are already familiar with. When they adopt the 
Swift practice of multiple extensions, they'll be confused why they have to 
change private to fileprivate, and may instead just decide to stick it all in 
one definition. Anecdotally, that's certainly what I expected when Swift 3 was 
released, and I've now stopped using extensions for types as much simply 
because of fileprivate.

> On Apr 7, 2017, at 10:01 PM, BJ Homer via swift-evolution 
>  wrote:
> 
> If private is required to be tied to types forever and always, then yes, this 
> proposal should be accepted. To do otherwise is to suggest that the use of 
> "private" by beginners and the use of same-file extensions by beginners are 
> incompatible. The former is silly; "private" is what beginners will naturally 
> reach for. The latter is possible, but historically the use of same-file 
> extensions has been quite idiomatic. So, I reluctantly agree we should accept 
> this proposal.
> 
> -BJ
> 
>> On Apr 7, 2017, at 10:34 PM, John McCall via swift-evolution 
>>  wrote:
>> 
>> 
 On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution 
  wrote:
 
 What is your evaluation of the proposal?
>>> 
>>> If this is the last option we have to change the status quo, any renaming 
>>> is off the table, no further changes after Swift 4, and it's either this or 
>>> being stuck with 'fileprivate' until the end of time, then +1 from me. It 
>>> will increase the convenience of access control for people like me who see 
>>> types and their extensions as parts of the same entity, just spread 
>>> visually across neighboring blocks. In almost any other language these two 
>>> would indeed be one entity, since most languages don't have any way of 
>>> dividing types into pieces this way.
>>> 
>>> However, IMHO any of these would be a better solution:
>> 
>> I'd like to respond briefly to this to clarify the Core Team's decisions 
>> about what solutions are under consideration, both now and in the future.  
>> By doing this, I don't mean to pressure you towards any particular stance.  
>> The Core Team asked for this to be proposed because we wanted to know how 
>> the community felt about it; we are not specifically trying to get it 
>> approved, at least as a group.
>> 
>>> 1) Rename 'private' to something else ('scoped'?) and rename 'fileprivate' 
>>> back to 'private'
>> 
>> The Core Team has rejected making such a major change in the interpretation 
>> of 'private'.  'private' will be tied to scopes, now and forever.  The only 
>> question is whether extensions of the same type within a file should be 
>> considered part of the same scope for the purposes of 'private'.  Swift 4 is 
>> the deadline for making that change; if it, too, is rejected, 'private' will 
>> be purely lexical forever.
>> 
>>> 2) Rename 'fileprivate' to something more friendly (I liked the 'local' 
>>> suggestion that Vladimir made today)
>> 
>> The Core Team is willing to consider adding a new keyword to replace 
>> 'fileprivate', but not in Swift 4.
>> 
>> Speaking just for myself, I don't think we'd accept such a change purely for 
>> aesthetics; it would have to be because 'fileprivate' seemed inappropriate 
>> for some new generalization, e.g. if we added sub-file submodules and wanted 
>> 'fileprivate' to allow access only within the submodule.  That is assuming a 
>> lot about how a future submodule feature would work, and we aren't going to 
>> design that feature specifically with a goal of replacing this keyword, and 
>> frankly we don't know when we're going to take that on at all.  I would 
>> caution people against assuming that 'fileprivate' will be renamed.
>> 
>>> 3) Postpone this until we add submodules, but with the assumption that it 
>>> will be possible to make some 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[BJ Homer via swift-evolution]

If private is required to be tied to types forever and always, then yes, this 
proposal should be accepted. To do otherwise is to suggest that the use of 
"private" by beginners and the use of same-file extensions by beginners are 
incompatible. The former is silly; "private" is what beginners will naturally 
reach for. The latter is possible, but historically the use of same-file 
extensions has been quite idiomatic. So, I reluctantly agree we should accept 
this proposal.

-BJ

> On Apr 7, 2017, at 10:34 PM, John McCall via swift-evolution 
>  wrote:
> 
> 
>>> On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution 
>>>  wrote:
>>> 
>>> What is your evaluation of the proposal?
>> 
>> If this is the last option we have to change the status quo, any renaming is 
>> off the table, no further changes after Swift 4, and it's either this or 
>> being stuck with 'fileprivate' until the end of time, then +1 from me. It 
>> will increase the convenience of access control for people like me who see 
>> types and their extensions as parts of the same entity, just spread visually 
>> across neighboring blocks. In almost any other language these two would 
>> indeed be one entity, since most languages don't have any way of dividing 
>> types into pieces this way.
>> 
>> However, IMHO any of these would be a better solution:
> 
> I'd like to respond briefly to this to clarify the Core Team's decisions 
> about what solutions are under consideration, both now and in the future.  By 
> doing this, I don't mean to pressure you towards any particular stance.  The 
> Core Team asked for this to be proposed because we wanted to know how the 
> community felt about it; we are not specifically trying to get it approved, 
> at least as a group.
> 
>> 1) Rename 'private' to something else ('scoped'?) and rename 'fileprivate' 
>> back to 'private'
> 
> The Core Team has rejected making such a major change in the interpretation 
> of 'private'.  'private' will be tied to scopes, now and forever.  The only 
> question is whether extensions of the same type within a file should be 
> considered part of the same scope for the purposes of 'private'.  Swift 4 is 
> the deadline for making that change; if it, too, is rejected, 'private' will 
> be purely lexical forever.
> 
>> 2) Rename 'fileprivate' to something more friendly (I liked the 'local' 
>> suggestion that Vladimir made today)
> 
> The Core Team is willing to consider adding a new keyword to replace 
> 'fileprivate', but not in Swift 4.
> 
> Speaking just for myself, I don't think we'd accept such a change purely for 
> aesthetics; it would have to be because 'fileprivate' seemed inappropriate 
> for some new generalization, e.g. if we added sub-file submodules and wanted 
> 'fileprivate' to allow access only within the submodule.  That is assuming a 
> lot about how a future submodule feature would work, and we aren't going to 
> design that feature specifically with a goal of replacing this keyword, and 
> frankly we don't know when we're going to take that on at all.  I would 
> caution people against assuming that 'fileprivate' will be renamed.
> 
>> 3) Postpone this until we add submodules, but with the assumption that it 
>> will be possible to make some source-breaking changes at that point
> 
> The Core Team is not willing to change the basic design of 'private' in 
> future releases of Swift.  If some feature — perhaps submodules — demands 
> that we define its interaction with 'private', the design of that interaction 
> will have to feel natural and consistent with the at-that-point extant design 
> of 'private'.  For example, it would not be acceptable if, say, adding a 
> submodule declaration to a file suddenly changed the interpretation of 
> 'private'.
> 
> An option (4) that you didn't list but which I should cover for completeness 
> would be to add new keywords in the future with new interpretations.  This is 
> something that the Core Team is willing to consider.  However, speaking just 
> for myself again, I find it unlikely that we would add new access control 
> features just to express increasingly-precise refinements; it would have to 
> be something that felt necessary because of some real inadequacy in the 
> existing access-control levels as applied to some other new feature (e.g. 
> submodules).
> 
> John.
> 
>> The thing I don't like about this proposal (or status quo) - apart from the 
>> fact that it will make people who like the current strict private unhappy - 
>> is that 'private' even right now means kind of two different things:
>> 
>> - for a property or a method defined in a class/struct, it means "available 
>> only inside this type"
>> - for a private global variable/constant/function, or a private type or 
>> extension, it means "available in this file" i.e. the same as 'fileprivate'
>> 
>> So if we're worried that this proposal makes the meaning of 'private' 
>> unclear - it 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[John McCall via swift-evolution]

> On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution 
>  wrote:
> 
> > What is your evaluation of the proposal?
> 
> If this is the last option we have to change the status quo, any renaming is 
> off the table, no further changes after Swift 4, and it's either this or 
> being stuck with 'fileprivate' until the end of time, then +1 from me. It 
> will increase the convenience of access control for people like me who see 
> types and their extensions as parts of the same entity, just spread visually 
> across neighboring blocks. In almost any other language these two would 
> indeed be one entity, since most languages don't have any way of dividing 
> types into pieces this way.
> 
> However, IMHO any of these would be a better solution:

I'd like to respond briefly to this to clarify the Core Team's decisions about 
what solutions are under consideration, both now and in the future.  By doing 
this, I don't mean to pressure you towards any particular stance.  The Core 
Team asked for this to be proposed because we wanted to know how the community 
felt about it; we are not specifically trying to get it approved, at least as a 
group.

> 1) Rename 'private' to something else ('scoped'?) and rename 'fileprivate' 
> back to 'private'

The Core Team has rejected making such a major change in the interpretation of 
'private'.  'private' will be tied to scopes, now and forever.  The only 
question is whether extensions of the same type within a file should be 
considered part of the same scope for the purposes of 'private'.  Swift 4 is 
the deadline for making that change; if it, too, is rejected, 'private' will be 
purely lexical forever.

> 2) Rename 'fileprivate' to something more friendly (I liked the 'local' 
> suggestion that Vladimir made today)

The Core Team is willing to consider adding a new keyword to replace 
'fileprivate', but not in Swift 4.

Speaking just for myself, I don't think we'd accept such a change purely for 
aesthetics; it would have to be because 'fileprivate' seemed inappropriate for 
some new generalization, e.g. if we added sub-file submodules and wanted 
'fileprivate' to allow access only within the submodule.  That is assuming a 
lot about how a future submodule feature would work, and we aren't going to 
design that feature specifically with a goal of replacing this keyword, and 
frankly we don't know when we're going to take that on at all.  I would caution 
people against assuming that 'fileprivate' will be renamed.

> 3) Postpone this until we add submodules, but with the assumption that it 
> will be possible to make some source-breaking changes at that point

The Core Team is not willing to change the basic design of 'private' in future 
releases of Swift.  If some feature — perhaps submodules — demands that we 
define its interaction with 'private', the design of that interaction will have 
to feel natural and consistent with the at-that-point extant design of 
'private'.  For example, it would not be acceptable if, say, adding a submodule 
declaration to a file suddenly changed the interpretation of 'private'.

An option (4) that you didn't list but which I should cover for completeness 
would be to add new keywords in the future with new interpretations.  This is 
something that the Core Team is willing to consider.  However, speaking just 
for myself again, I find it unlikely that we would add new access control 
features just to express increasingly-precise refinements; it would have to be 
something that felt necessary because of some real inadequacy in the existing 
access-control levels as applied to some other new feature (e.g. submodules).

John.

> The thing I don't like about this proposal (or status quo) - apart from the 
> fact that it will make people who like the current strict private unhappy - 
> is that 'private' even right now means kind of two different things:
> 
> - for a property or a method defined in a class/struct, it means "available 
> only inside this type"
> - for a private global variable/constant/function, or a private type or 
> extension, it means "available in this file" i.e. the same as 'fileprivate'
> 
> So if we're worried that this proposal makes the meaning of 'private' unclear 
> - it already is unclear. Wouldn't it be much more clear if private global 
> variables, functions and classes were required to use the access level that 
> means "available in this file", since that's how they actually work? (as long 
> as this level is not named 'fileprivate' :)
> 
> And the other access level, the "available only inside this type" (private / 
> scoped), could only be used for things that are actually contained inside a 
> type, and wouldn't have two different meanings depending on whether it's at 
> the root of the file or nested inside something else.
> 
> I really believe that even though this is kind of painful for everyone, it's 
> worth spending time to figure out a solution that satisfies most 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Jakub Suder via swift-evolution]

> What is your evaluation of the proposal?

If this is the last option we have to change the status quo, any renaming
is off the table, no further changes after Swift 4, and it's either this or
being stuck with 'fileprivate' until the end of time, then +1 from me. It
will increase the convenience of access control for people like me who see
types and their extensions as parts of the same entity, just spread
visually across neighboring blocks. In almost any other language these two
would indeed be one entity, since most languages don't have any way of
dividing types into pieces this way.

However, IMHO any of these would be a better solution:

1) Rename 'private' to something else ('scoped'?) and rename 'fileprivate'
back to 'private'

2) Rename 'fileprivate' to something more friendly (I liked the 'local'
suggestion that Vladimir made today)

3) Postpone this until we add submodules, but with the assumption that it
will be possible to make some source-breaking changes at that point

The thing I don't like about this proposal (or status quo) - apart from the
fact that it will make people who like the current strict private unhappy -
is that 'private' even right now means kind of two different things:

- for a property or a method defined in a class/struct, it means "available
only inside this type"
- for a private global variable/constant/function, or a private type or
extension, it means "available in this file" i.e. the same as 'fileprivate'

So if we're worried that this proposal makes the meaning of 'private'
unclear - it already is unclear. Wouldn't it be much more clear if private
global variables, functions and classes were required to use the access
level that means "available in this file", since that's how they actually
work? (as long as this level is not named 'fileprivate' :)

And the other access level, the "available only inside this type" (private
/ scoped), could only be used for things that are actually contained inside
a type, and wouldn't have two different meanings depending on whether it's
at the root of the file or nested inside something else.

I really believe that even though this is kind of painful for everyone,
it's worth spending time to figure out a solution that satisfies most of us
and makes the language clearer and friendlier in the long term, even if it
means breaking compatibility again. Do we want to be stuck with an
imperfect solution 10 years from now, because we didn't want to do this
last breaking change now?


> Is the problem being addressed significant enough to warrant a change to
Swift?

I think almost everyone here agrees it is significant.


> Does this proposal fit well with the feel and direction of Swift?

This is a difficult question. IMHO it would definitely fit much better with
the direction of Swift if we bit the bullet and did whatever we agree will
make the language simpler and better long term, regardless how many changed
lines in git this will cause when Swift 4 is released.


> If you have used other languages or libraries with a similar feature, how
do you feel that this proposal compares to those?

I've used many languages, but I think in none of them it was a common thing
(or even a possibility) to split types into several blocks like we do in
Swift with extensions, so the main issue we're talking about didn't exist
there. In Ruby you can kind of do the same thing with modules - if you have
a private method in a module, you can access it from methods in the main
type, even if they're defined in a different file. (But Ruby isn't very
strict about access control in general, e.g. it allows you to call private
methods on any object via #send).


> How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

I've read or skimmed through most of the messages in the recent threads
about this and the last proposal.

Disclaimer: I have very little experience with Swift 3 (but plenty with
Swift 2.x).

Kuba
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Vladimir.S via swift-evolution]

On 07.04.2017 16:56, Shawn Erickson via swift-evolution wrote:

-1 (strongish) on this proposal for the reason I comment earlier in the
discussion thread.

This weakens private for not an atypical use case of private that I
currently have. It muddies the water between fileprivate and private making
private more confusing and in away surprising. We have a clear and explicit
way in fileprivate to do what this proposal does by tweaking private. I get
that folks don't like fileprivate the word but I don't see that being a
strong enough reason to take things in this direction. It also builds on
file based access scoped which I believe is not the direction we should be
going in a modern language such as swift.

If changes are this strongly desired I believe we should bite the bullet
and rename "private" to "scope[d]" and "fileprivate" to "private". Then
work on making this renamed private work across files coupled either with a
submodule concept (likely tagging wholes file as existing in a module)
and/or making it work across extensions or class trees. ...or as suggested
by others leave "private" as is and just rename "fileprivate" to "shared"


.. or to "local", as "shared" is confusing if it is shared with all module. 
The meaning of "local" is also not 100% obvious, but:

* IMO it is not hard to tech public->internal->local->private
(internal for module, local for file/submodule, private for scope)
* Don't need to change anything in meaning of current access modifiers
* We even can keep 'fileprivate' as an alias(depricated?) for 'local', so 
we can have 100% source compatibility
* 'local' is very short and good looking keyword, that's important given it 
will be used often
* 'private' still be the most strict access level, soft default. Then you 
can promote to next level('local') if decide you need wider access scope.
* Yes, I remember, 'local' was rejected previously, but world is changing, 
currently many(most?) of us agree that 'fileprivate' more harmful than 
other not clear meaning but good looking word; that 'fileprivate' is still 
used very often and *will* be used often; and IIRC during the SE-0025 there 
was an intention to fix *later* awkward 'fileprivate' keyword, but now we 
was told "this is the last chance, nothing related to access modifiers will 
be in scope of any future Swift and renaming is not in scope of current 
stage also". So given this all, I think we can re-consider 'local' keyword.


Seems like such proposal also will have a huge support of the community.

Btw, when was *that* moment(which most of us missed, as I understand) we 
were *allowed* to discuss access modifier changes?



or something like that so it can expand it capability as I outline a
sentence earlier.

This proposal doesn't help like I think a more comprehensive rework would,
it actually hurts my usage of current private.



On Thu, Apr 6, 2017 at 4:10 PM Douglas Gregor > wrote:

Hello Swift community,

The review of SE-0169 "Improve Interaction Between private Declarations
and Extensions" begins now and runs through April 11, 2017. The
proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md

Reviews are an important part of the Swift evolution process. All
reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager. When replying, please try to keep the proposal link at
the top of the message:

Proposal link:


https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md

Reply text

Other replies


  
  
What
  goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction
of Swift. When writing your review, here are some questions you might
want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a
change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Doug

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Shawn Erickson via swift-evolution]

-1 (strongish) on this proposal for the reason I comment earlier in the
discussion thread.

This weakens private for not an atypical use case of private that I
currently have. It muddies the water between fileprivate and private making
private more confusing and in away surprising. We have a clear and explicit
way in fileprivate to do what this proposal does by tweaking private. I get
that folks don't like fileprivate the word but I don't see that being a
strong enough reason to take things in this direction. It also builds on
file based access scoped which I believe is not the direction we should be
going in a modern language such as swift.

If changes are this strongly desired I believe we should bite the bullet
and rename "private" to "scope[d]" and "fileprivate" to "private". Then
work on making this renamed private work across files coupled either with a
submodule concept (likely tagging wholes file as existing in a module)
and/or making it work across extensions or class trees. ...or as suggested
by others leave "private" as is and just rename "fileprivate" to "shared"
or something like that so it can expand it capability as I outline a
sentence earlier.

This proposal doesn't help like I think a more comprehensive rework would,
it actually hurts my usage of current private.



On Thu, Apr 6, 2017 at 4:10 PM Douglas Gregor  wrote:

> Hello Swift community,
>
> The review of SE-0169 "Improve Interaction Between private Declarations
> and Extensions" begins now and runs through April 11, 2017. The proposal is
> available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager. When replying, please try to keep the proposal link at the
> top of the message:
>
> Proposal link:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
>
> Reply text
>
> Other replies
>
>
> What
> goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
>- What is your evaluation of the proposal?
>- Is the problem being addressed significant enough to warrant a
>change to Swift?
>- Does this proposal fit well with the feel and direction of Swift?
>- If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?
>- How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Doug
>
> Review Manager
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 7 Apr 2017, at 00:25, Slava Pestov via swift-evolution 
>  wrote:
> 
> Strong -1. This is a source breaking change, but Swift 4 stage 2 is already 
> over.

Considering the importance of access control for a lot of people and the rare 
chance to do something about it, that looks a bit like a technicality Slava, no 
offence meant :)

> 
> Slava
> 
>> On Apr 6, 2017, at 4:10 PM, Douglas Gregor  wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0169 "Improve Interaction Between private Declarations and 
>> Extensions" begins now and runs through April 11, 2017. The proposal is 
>> available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> or, if you would like to keep your feedback private, directly to the review 
>> manager. When replying, please try to keep the proposal link at the top of 
>> the message:
>> 
>> Proposal link:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
>> Reply text
>> Other replies
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. When writing your review, here are some questions you might want to 
>> answer in your review:
>> 
>> What is your evaluation of the proposal?
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
>> Does this proposal fit well with the feel and direction of Swift?
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
>> More information about the Swift evolution process is available at
>> 
>> https://github.com/apple/swift-evolution/blob/master/process.md
>> Thank you,
>> 
>> -Doug
>> 
>> Review Manager
>> 
>> ___
>> swift-evolution-announce mailing list
>> swift-evolution-annou...@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Michel Fortin via swift-evolution]

> Proposal link:
> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md

> What is your evaluation of the proposal?

I don't understand the need for this: when you need things to be accessible 
elsewhere in the file you can already use `fileprivate`. To me it looks like we 
are trying to change the semantics of `private` to be closer to `fileprivate` 
simply because `fileprivate` has been labeled as an undesirable.

The motivation section of the proposal talks about "the prevalence of 
fileprivate" as if that was a horrendous thing. I disagree with this implicit 
assertion and I will claim that `fileprivate` actually makes a better soft 
default.

I happen to also disagree that this is a narrow change. It's true that in some 
files (those with no extensions) this will have absolutely zero impact; in many 
others (those made of a type and dozen of extensions to that same type) it'll 
make `private` equivalent to `fileprivate`. While it can be narrow in some 
cases, in others it is effectively quite similar to getting rid of `private`. 
SE-0159 was rejected because it removed scoped-private and this is not much 
different.

In the end, this change might achieve the goal of making `fileprivate` used 
less often, but only because `private` becomes very close to `fileprivate` in 
the common case of having a type defined with many extensions as part of the 
same file. I doubt the small difference between `fileprivate` and `private` 
that would remain is enough to justify having two access levels. If we were 
designing from scratch, we'd only keep one of the two and get rid of the other 
as mostly redundant.


> Is the problem being addressed significant enough to warrant a change to 
> Swift?

I think there is a significant problem with access control, but it is ill 
defined. There is nothing inherently wrong with the prevalence of `fileprivate` 
(other than how it's called).


> Does this proposal fit well with the feel and direction of Swift?

I have to admit I find it hard to decipher "the direction of Swift" when it 
comes to access control since SE-0025. My own direction of Swift now is that I 
try to use `fileprivate` instead of `private` unless there is a good reason to 
use `private`. Even though it looks a bit strange at first glance, it has the 
semantics I generally want.

This proposal might make using `private` work in more cases, so I should be 
thrilled, right? I'm not that thrilled because with the semantics being closer 
to `fileprivate` it'll become less obvious which one should be used in which 
situations.


> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?

Not sure there's anything left to compare to at this point.


> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

Read most messages on this topic on the list and replied occasionally.


-- 
Michel Fortin
https://michelf.ca

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Brent Royal-Gordon via swift-evolution]

Proposal link:

> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md


> On Apr 6, 2017, at 4:10 PM, Douglas Gregor  wrote:
> 
> What is your evaluation of the proposal?
This proposal is actively harmful. It will push people into using patterns we 
discourage, like converting between types by using properties or methods on the 
source type instead of initializers on the destination type. It will cause 
people to distort their designs, moving implementations into different types 
solely to gain access to `private` members.

I don't like scoped `private` either, but at least it has its uses: It's an 
effective tool when a member has fragile, easily-broken invariants and you want 
to ensure only carefully-audited code can use it. Type-and-file `private` is 
not fit for this purpose: Even if you segregate the fragile parts into a 
separate type, you can just extend that separate type anywhere else in the file 
and start messing with it. Frankly, I don't think type-and-file `private` is 
fit for *any* purpose.

At the same time, type-and-file `private` does not simplify our access modifier 
scheme, forces people to re-learn what `private` does *again*, and silently 
removes the protection that people currently rely on scoped `private` to 
provide without so much as a whimper from the compiler.

Keeping scoped `private` offers the following virtues:

* Your code doesn't change meaning or protection
* You don't have to re-learn what `private` means
* You can tightly protect fragile parts of a type, completely limiting 
visibility to one small region of the code

Making `private` and `fileprivate` aliases for one another offers the following 
virtues:

* You will never have to use the ugly `fileprivate` keyword
* Teaching and explaining access control is simpler
* You never have to put any piece of code in any particular type

Giving `private` type-and-file semantics offers the following virtues:

* You (hopefully) will have to use the ugly `fileprivate` keyword a little less 
often

That's it. That's *absurdly* far from being worth it.

This proposal is the worst of both worlds: weaker encapsulation without 
simplification, bad incentives without good guarantees, complexity without 
benefit, change without improvement. It should be rejected.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Access control is a mess, but this proposal does not address the things that 
make it a mess.

> Does this proposal fit well with the feel and direction of Swift?
No. This is a direction we have specifically and repeatedly chosen not to go in 
for many very good reasons. Those reasons still hold.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
Swift 2's design was simple and elegant. Swift 3's was irritating but sometimes 
useful. This proposal keeps the irritation while discarding the usefulness.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

Like all of us, I have spent *way* too much time arguing about access control 
in the last few months.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Xiaodi Wu via swift-evolution]

For the reasons I outlined previously, a very strong -1 as well.

I thought it was worthwhile to consider if the Swift 2 design was superior
to the Swift 3 design, but I feel very strongly that there should not be a
Swift 4 "private" that's different from both Swift 3 and 2.
On Thu, Apr 6, 2017 at 18:25 Slava Pestov via swift-evolution <
swift-evolution@swift.org> wrote:

> Strong -1. This is a source breaking change, but Swift 4 stage 2 is
> already over.
>
> Slava
>
> On Apr 6, 2017, at 4:10 PM, Douglas Gregor  wrote:
>
> Hello Swift community,
>
> The review of SE-0169 "Improve Interaction Between private Declarations
> and Extensions" begins now and runs through April 11, 2017. The proposal is
> available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager. When replying, please try to keep the proposal link at the
> top of the message:
>
> Proposal link:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
>
> Reply text
>
> Other replies
>
>
> What
> goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
>- What is your evaluation of the proposal?
>- Is the problem being addressed significant enough to warrant a
>change to Swift?
>- Does this proposal fit well with the feel and direction of Swift?
>- If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?
>- How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Doug
>
> Review Manager
> ___
>
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Slava Pestov via swift-evolution]

Strong -1. This is a source breaking change, but Swift 4 stage 2 is already 
over.

Slava

> On Apr 6, 2017, at 4:10 PM, Douglas Gregor  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0169 "Improve Interaction Between private Declarations and 
> Extensions" begins now and runs through April 11, 2017. The proposal is 
> available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
>  
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
>  
> 
> Reply text
> Other replies
>  
> What
>  goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thank you,
> 
> -Doug
> 
> Review Manager
> 
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution