[Review] SE-0159: Fix Private Access Levels


(Douglas Gregor) #1

Hello Swift community,

The review of SE-0159 "Fix Private Access Levels" begins now and runs through March 27, 2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.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/0159-fix-private-access-levels.md
Reply text
Other replies
<https://github.com/apple/swift-evolution/blob/master/process.md#what-goes-into-a-review-1>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


Access control below public [not `protected`]
(Riley Testut) #2

What is your evaluation of the proposal?

A huge +1. I separate the implementation of all my types into extensions, and this practice resulted in me almost always having to use the fileprivate keyword. Personally, I also have never needed any further access controls than those available in Swift 2, even after writing Swift 3 code since its release.

Additionally, it’s a weird inconsistency that top-level “private” declarations are treated like fileprivate, so happy that this will fix that as well.

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

100%.

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

Yes. Simplifies the access control model by removing a fringe feature (in my opinion).

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

Private still doesn’t match the definition of other languages after this change, but I don’t think that’s a bad thing.

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

Followed the discussion, and read through the final proposal.

···

On Mar 20, 2017, at 4:54 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of SE-0159 "Fix Private Access Levels" begins now and runs through March 27, 2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.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/0159-fix-private-access-levels.md
Reply text
Other replies
<https://github.com/apple/swift-evolution/blob/master/process.md#what-goes-into-a-review-1>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 mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Jon Hull) #3

What is your evaluation of the proposal?

+0.75

I agree that this is better than what we have now. I wonder though, if we should just mark it as “a change we want to make”, and then actually make the change at the same time as we add submodules, etc… I would hate to have to make another small change to this in the future to accommodate those features right after changing this again now. (or worse, I would hate to feel like we were blocked from making necessary changes in the future because of churn caused by this).

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

Yes, I think so.

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

Yes

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

Swift does it’s own thing here, but I like it.

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

A fair amount of thought during the discussion. A little bit right now.


(Austin Zheng) #4

https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
What is your evaluation of the proposal?

+1.

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

Yes. Adding a fourth level of access control has greatly increased the complexity of the language (search the mailing lists for various discussions about corner case behavior caused by the existence of the new scope-level 'private') for (what I believe to be) very little benefit.

To be clear, I am not opposed to additional access control levels in principle. Swift might require more powerful access control in the future. There seems to be a consensus that Swift should gain some sort of code organization facility, whether in the form of namespaces, submodules, or something similar. Any additions to the access control system should take into account whatever solution to this code organization problem Swift eventually decides to go with, and should address a pain point that a wide range of Swift developers have actually experienced (since any such addition is going to add some level of unavoidable complexity which every developer will need to deal with).

In my opinion, the Swift 3 behavior fails both of these tests and should be deprecated.

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

Absolutely.

It is extremely easy to add features to a language. While we try our best, we cannot predict all the consequences of adding a feature. Nor do we always make a good judgement as to whether the complexity added by such features is justified by the additional functionality they provide. Removing features is more difficult: the window to do so without imposing undue burden on developers is small, almost every feature is going to be used by at least a handful of developers, and removing functionality is intrinsically less appealing than adding it.

Yet in decision after decision the core team has reiterated their desire to not add features simply because they might be useful, but rather to rigorously ensure that new features "earn their keep" in terms of additional power versus complexity. Past experience has shown that this is often the right decision, and that removing features that fail this test will not seriously damage the language or community.

Admitting that we erred and accepting this proposal does *not* affect our ability to thoughtfully improve the access control system in the future. Rejecting it ensures that all proposals to improve access control in the future, including proposals that could supersede the functionality of Swift 3's 'private', are necessarily going to be more difficult to understand and more difficult to implement than they would be otherwise.

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

While not a perfect system, the concept of private and public header files in Objective-C (and true 'private' declarations at the top of a source file) has, in my experience, been adequate for the needs of a variety of different types of software, including projects being worked on by small and large teams, as well as both libraries and applications. Swift 2's three-level access control system was a refinement of this previous convention and, in my opinion, struck the proper balance between granularity, safety, and programmer ergonomics.

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

I read the proposal when it was first presented and have followed many, many threads about both the proposal and about 'private' and 'fileprivate' on the lists.

···

On Mar 20, 2017, at 4:54 PM, Douglas Gregor <dgregor@apple.com> wrote:

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-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce


(David Waite) #5

Hello Swift community,

The review of SE-0159 "Fix Private Access Levels" begins now and runs through March 27, 2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
What is your evaluation of the proposal?

I’m conflicted. This is generally better than the current state, but I worry that we may want to change access levels in an incompatible way yet again in the future.

The problem isn’t with private as defined today, but that there is a desire for access control levels in between private and internal.

My opinion - the biggest issue with fileprivate is that it is close enough to not have a clear distinction of *why* a developer would choose fileprivate over private - the distinction is left meaningless unless defined for the project as part of coding standards.

In many languages, a scoped “private" has a clear meaning - protecting methods and state which could cause an external party to misuse the type - break class invariants, break threading model, and so on.

The reverted “private” does not have that meaning - extensions and other types within the same file have the ability to misuse the type to break all the above.

For that reason, I think it is important in evaluation to decide just how important a scoped “private” protecting type internal code. If it is important, I’d recommend deferring making this change, and instead shoot for a future where ‘private' remains the same but ‘fileprivate’ is replaced with something more powerful.

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

Yes

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

As stated in the evaluation above, I believe this is dependent on whether submodules, multi-module frameworks, or friend access will modify access control in the future. In that case, I worry that we would actually prefer having the scoped private in concert with the new access modifiers, and would recommend deferring change.

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

In-depth study/lots of arguing and use of the existing (and Swift 2) system

-DW

···

On Mar 20, 2017, at 5:54 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:


(Chéyo Jiménez) #6

What is your evaluation of the proposal?

+1

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

Yes. Making scope private be the soft default (private) created much confusion . The incredible overlap that this change created for fileprivate and private is actively harmful. Reverting this now will allow a more powerful scope access to be added much later in conjunction with a comprehensive module system.

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

Yes.

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

Swift 1 and 2.
Simple.
Easy to understand.
Worked great with extensions.

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

Participated extensibly on the conversations leading to the proposal.


(Jarod Long) #7

• What is your evaluation of the proposal?

I think it could stand to make a bit of a stronger case, but I am strongly in favor of the outcome. The introduction of fileprivate was disappointing to me when it happened, and I've yet to encounter a situation where it has been beneficial, but it has often been frustrating.

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

I think so -- I believe that it's very important for this sort of fundamental language feature to be simple and pleasant to use. The tradeoffs that fileprivate makes in that regard feel pretty significant to me, and I don't think the additional level of control is of much benefit.

I would go as far as to say that scoped access control is harmful in that it promotes bad programming practices. If your file is large enough that there is value in protecting yourself from accessing certain parts of it, that file is almost certainly excessively large and difficult to follow.

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

I believe that it does to the extent that Swift strives to avoid overburdening its users with low-value features.

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

I used Swift prior to version 3, and I strongly preferred the previous access control model.

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

I read the proposal fully and have been casually following much of the discussion on this topic.

Jarod

···

On Mar 20, 2017, 16:54 -0700, Douglas Gregor via swift-evolution , wrote:

Hello Swift community,
The review of SE-0159 "Fix Private Access Levels" begins now and runs through March 27, 2017. The proposal is available here:
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.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/0159-fix-private-access-levels.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 mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Greg Parker) #8

-1. I yield the remainder of my time to Drew Crawford who satisfactorily explained my concerns.

···

On Mar 20, 2017, at 4:54 PM, Douglas Gregor <dgregor@apple.com> wrote:

Hello Swift community,

The review of SE-0159 "Fix Private Access Levels" begins now and runs through March 27, 2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md

--
Greg Parker gparker@apple.com Runtime Wrangler


(Drew Crawford) #9

I disagree quite strongly with the proposal.

First, the document draws conclusions without apparent supporting evidence, e.g.

Since the release of Swift 3, the access level change of SE–0025 was met with dissatisfaction by a substantial proportion of the general Swift community. Those changes can be viewed as actively harmful, the new requirement for syntax/API changes.

What is “dissatisfaction by a substantial proportion of the general Swift community”? How was this measured/determined?
What was done to control for the population happy with SE-0025 who would e.g. not be likely to take up pitchforks?
Who argues these changes are “actively harmful” and where were they during SE-0025?

subtly encourages overuse of scoped access control and discourages the more reasonable default

Who claims that scoped access is “overused” and what is their argument for doing so?
Why is “fileprivate” the “more reasonable default”? In fact neither fileprivate *nor* private are default (reasonable or not!). Internal is the default. Nor does this proposal suggest we change that. So this seems a very strange statement.

But is that distinction between private and fileprivate actively used by the larger community of Swift developers?

Yes. To cite some evidence, here are codebases I actively maintain:

codebase | private # | fileprivate # | ratio |

--------------------------------------------------------|-----------|---------------|-------|

"M" (proprietary) | 486 | 249 | 2x |

"N"(proprietary) | 179 | 59 | 3x |

NaOH https://code.sealedabstract.com/drewcrawford/NaOH | 15 | 1 | 15x |

atbuild https://github.com/AnarchyTools/atbuild | 54 | 5 | 11x |

So from my chair, not only is the distinction useful, but scoped access control (private) is overwhelmingly (2-15x) more useful than fileprivate.

And if it were used pervasively, would it be worth the cognitive load and complexity of keeping two very similar access levels in the language? This proposal argues that answer to both questions is no

This proposal does not make any later argument about “cognitive load” or “complexity” I can identify. Did the proposal get truncated?

What is stated (without evidence) is that "it is extremely common to use several extensions within a file” and that use of “private” is annoying in that case. I now extend the above table

codebase | private # | fileprivate # | ratio | # of extensions (>=3 extensions in file) |

--------------------------------------------------------|-----------|---------------|-------|------------------------------------------|

"M" (proprietary) | 486 | 249 | 2x | 48 |

"N"(proprietary) | 179 | 59 | 3x | 84 |

NaOH https://code.sealedabstract.com/drewcrawford/NaOH | 15 | 1 | 15x | 3 |

atbuild https://github.com/AnarchyTools/atbuild | 54 | 5 | 11x | 6 |

in order to demonstrate in my corner of Swift this is not “extremely common”, and is actually less popular than language features the proposal alleges aren’t used.

My point here is that **different people in different corners of the community program Swift differently and use different styles**. I can definitely empathize with folks like the author who use extensions to group functions and are annoyed that their favorite visibility modifier grew four extra characters. Perhaps we can come up with a keyword that is more succint.

However, that is no reason to take away features from working codebases. A scoped access modifier is perhaps my favorite feature in Swift 3. Let’s not throw stuff away because it adds extra characters to one programming style.

Finally, SE-0025 establishes clear motivation for the scoped access modifier:

Currently, the only reliable way to hide implementation details of a class is to put the code in a separate file and mark it as private. This is not ideal for the following reasons:

It is not clear whether the implementation details are meant to be completely hidden or can be shared with some related code without the danger of misusing the APIs marked as private. If a file already has multiple classes, it is not clear if a particular API is meant to be hidden completely or can be shared with the other classes.

It forces a one class per file structure, which is very limiting. Putting related APIs and/or related implementations in the same file helps ensure consistency and reduces the time to find a particular API or implementation. This does not mean that the classes in the same file need to share otherwise hidden APIs, but there is no way to express such sharability with the current access levels.

As far as I can see, the proposal does not actually address or acknowledge these problems at all, but cheerfully returns us to them. It would be a mistake to deprecate this feature without examining at all why we introduced it. And realistically we need new solutions to those problems before removing the existing one.

Drew

···

On March 20, 2017 at 6:54:55 PM, Douglas Gregor (dgregor@apple.com) wrote:

Hello Swift community,

The review of SE–0159 “Fix Private Access Levels” begins now and runs through March 27, 2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.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/0159-fix-private-access-levels.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-announce@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution-announce


(Vanderlei Martinelli) #10

- What is your evaluation of the proposal?

Huge +1.

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

Yes. I would like to see the `private` as it was before (and introduce a
new `local` keyword for scoped access, but that is another history).

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

For sure.

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

Swift 1.x and Swift 2.x. It is different from other programming languages,
but it is already incorporated by the Swift developers.

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

I read the proposal when it was first presented and have followed many,
many threads about both the proposal and about 'private' and 'fileprivate'
on the lists.

···

On Mon, Mar 20, 2017 at 8:54 PM, Douglas Gregor <dgregor@apple.com> wrote:

Hello Swift community,

The review of SE-0159 "Fix Private Access Levels" begins now and runs
through March 27, 2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/
proposals/0159-fix-private-access-levels.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/0159-fix-private-access-levels.md

Reply text

Other replies

<https://github.com/apple/swift-evolution/blob/master/process.md#what-goes-into-a-review-1>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-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce


(Brent Royal-Gordon) #11

I'm torn. During the SE-0025 review, I argued against scoped private. I still think it was a mistake to add it. But we did, it's out there, and I don't want to introduce churn unnecessarily.

Long ago, judges realized the problems caused by re-litigating old disputes and created a doctrine called "stare decisis": standing by things decided. That doesn't mean they won't correct obvious mistakes, but it does mean that they default to upholding the precedent they've already set. I think that would be a wise course here.

I personally would prefer to have Swift behave as SE-0159 proposes. But if the core team thinks this is going to come out 50/50—that is, this change will help about as many people as it hurts—I think they should reject this proposal and keep the status quo. I really don't want to write another review next year for SE-0289 "Reintroduce Scoped Private".

···

On Mar 20, 2017, at 4:54 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md

  • What is your evaluation of the proposal?

--
Brent Royal-Gordon
Architechies


(Tony Allevato) #12

Hello Swift community,

The review of SE-0159 "Fix Private Access Levels" begins now and runs
through March 27, 2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.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/0159-fix-private-access-levels.md

Reply text

Other replies

<https://github.com/apple/swift-evolution/blob/master/process.md#what-goes-into-a-review-1>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?

Major +1.

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

Absolutely. Distinguishing between private and fileprivate adds little

value; it mainly serves to protect authors from themselves since it's not
possible for an outside entity to insert its own code into the compilation
unit after it's been compiled*. It's very difficult to see the benefit of
having developers auditing individual members' visibilities to such a fine
degree.

(* The same could be said for file-private because of module boundaries,
but distinguishing between module-restricted and file-restricted has value
for large projects where multiple authors may contribute to the same module
quasi-independently. It's also crucial in code-generation cases like
protocol buffers where the generator doesn't have control over the module
into which the code will be compiled and you still want to be able to use
file-private to hide some details of the generated code from clients in the
same module.)

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

Yes. One of the most attractive things about Swift's original visibility

model was its simplicity. SE-0025 opened the door to numerous later
informal proposals that would have added even finer distinctions to the
visibility model which would have made the language even more complex.

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

Earlier versions of Swift.

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

Followed numerous conversations/threads about the topic and read this
proposal.

···

On Mon, Mar 20, 2017 at 4:54 PM Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote:

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 mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Rien) #13

+1

  • What is your evaluation of the proposal?

Makes the language easier to understand, lowers cognitive load during coding.
I also hope this will pave the way for a overhaul of the access level system including modularization.

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

yes.

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

Yes

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

private vs fileprivate seems swift-only, as such I have no comparison.

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

Followed and participated in the discussions.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl

···

On 21 Mar 2017, at 00:54, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of SE-0159 "Fix Private Access Levels" begins now and runs through March 27, 2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.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/0159-fix-private-access-levels.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 mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(James Berry) #14

-1.

While I agree generally that access control in swift is not yet perfect, I feel strongly that any further reshaping of access control primitives should wait until a submodule design is in place. To do another zag on this issue at this point seems preliminary, tweaky, and almost capricious towards our users. The access primitives established by SE-0025 added further control. Some may not like the naming. But it seems to me that as we contemplate potential further shifts down the line with submodules, we’re better off starting from where we are today, at a higher level of specificity.

Hello Swift community,

The review of SE-0159 "Fix Private Access Levels" begins now and runs through March 27, 2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md

What is your evaluation of the proposal?

The proposal doesn’t to me meet the high hurdles for change in the swift 4 timeframe. The current situation isn’t broken or horrible. I believe the SE-0025 semantics better position us for any access level changes that may be required if submodules are adopted.

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

No

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

No

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

I feel this proposal goes in the wrong direction vis-a-vis expectations for access control.

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

I’ve closely followed SE-0025 and SE-0159 discussions across the immense breadth of space and time they have consumed.

···

On Mar 20, 2017, at 4:54 PM, Douglas Gregor <dgregor@apple.com> wrote:


(Mark Sands) #15

- What is your evaluation of the proposal?

+0.5, with my preference being Alternative 2

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

Yes. Others have pointed out that "the extension problem" could be
addressed by giving extensions access to private members within a module,
which would solve a lot of my grief but make fileprivate less applicable in
general.

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

Yes

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

No comment.

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

A quick refresher of 25 and a quick reading of 159

···

On Mon, Mar 20, 2017 at 6:54 PM, Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote:

Hello Swift community,

The review of SE-0159 "Fix Private Access Levels" begins now and runs
through March 27, 2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/
proposals/0159-fix-private-access-levels.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/0159-fix-private-access-levels.md

Reply text

Other replies

<https://github.com/apple/swift-evolution/blob/master/process.md#what-goes-into-a-review-1>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 mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Michel Fortin) #16

  • What is your evaluation of the proposal?

Renaming `fileprivate` to `private` makes sense. In my code, I use `fileprivate` and `private` interchangeably, meaning that I write `private` for things that shouldn't be leaked to the whole module and if by chance the compiler complain I'll change it to `fileprivate` without a second thought. This tells me that I'm using the feature wrong: I should be writing `fileprivate` everywhere and narrowing it to `private` only where it is really important that I do so. But a name like `fileprivate` makes this rather difficult.

So I'd be glad to see that problem go away.

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

I think it is significant enough. I think the core team's evaluation for Swift 3 that `fileprivate` would be rarely used was completely mistaken. Worse, forcing the use of the dirtier word `fileprivate` is draining all thoughtful intent from `private` in Swift 3. It's not a good thing when `private` is used only because it compiles and changed to `fileprivate` on a whim whenever the compiler complains.

While I don't have much attachment to the scoped-private concept, I'm not convinced its total removal is necessary either. Alternative 3 might solve this problem with less disruption to the language. While it offers some room to replicate the same problem I described above -- with different keywords -- I feel using a word like `scoped` would be less prone to overuse than `private` and therefore more truthful to the actual intent. If so, that would fix the problem too.

Either way, something must be done.

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

I think it does. The conflation of `private` and `fileprivate` at the top level of the file always sounded indicative to me of a flaw in the design. Correcting this would be an improvement.

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

I'm used to D where `private` has the pretty much same meaning as `fileprivate` in Swift. I never found that much of a problem. But I've seen similar debates there too.

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

I've read the proposal and most of the discussion, even though I haven't participated much.

···

--
Michel Fortin
https://michelf.ca


(Colin Barrett) #17

Hello Swift community,

The review of SE-0159 "Fix Private Access Levels" begins now and runs
through March 27, 2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.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/0159-fix-private-access-levels.md

Reply text

Other replies

<https://github.com/apple/swift-evolution/blob/master/process.md#what-goes-into-a-review-1>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?

-1. The proposal does not make a convincing case for why this is a

problem.

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

Having to write "fileprivate" seems like a pretty minor annoyance.

Especially when compared to having to move any desired private data to a
new file. In my view, the primary purpose of access modifiers below
internal is to keep autocomplete from suggesting implementation details to
clients.

···

On Mon, Mar 20, 2017 at 7:54 PM Douglas Gregor <dgregor@apple.com> wrote:
,

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

Given that in other places in Swift, scoping often corresponds with

lexical structure, making "private" an exception seems surprising.
"fileprivate" succinctly communicates this oddity.

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

I've got a decent amount of experience with access control in Java,

Python, Haskell, and Standard ML.

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

I read the proposal once. (I didn't have time to read the follow-ups

on-list, apologies for any noise.)

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-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce


(David Rönnqvist) #18

What is your evaluation of the proposal?

I’m positive towards this proposal in isolation. It’s a step in the right direction. But I also feel that it doesn’t fully address the larger issue around access control.

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

The larger problem of access control definitely is. I can agree that the changes of SE-0025 were confusing and could be seen as harmful. If there’s a larger overhaul of access control coming in the future, then I’m not certain that the fileprivate/private problem is significant enough to warrant a change. But if there might be some time before there is a chance to revisit access control, then this might be significant enough to do now.

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

Yes.

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

Objective-C effectively has a file based private access by not really having access control :wink: and commonly putting “private” declarations in a category in the .m file.
Languages like Java has access control that is more targeted towards subclassing, where files doesn’t matter.
Languages like Haskell has access control based on files or modules, largely because of free functions.

Swift isn’t exactly like either of these. It has proper enforceable access control, it has protocols and extensions, it prefers properties and member functions over free functions.
I can’t think of any other language that has both a private and a file private scope. And if Swift were to have only one (again), then file private feels right for Swift, mainly for its use in same-file extensions.

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

Read the proposal and participated in one of the the discussions leading up to it.


(Christopher Kornher) #19

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?
-1

Is the problem being addressed significant enough to warrant a change to Swift?
Not on its own. I believe that it would be better for the community to handle this as part of a thorough look at Sub Modules and code organization. It is possible that this will be modified yet again when submodules/packages are addressed, creating yet more churn.

Access modifiers should not much of an issue for beginners and small projects. The current rules are useful for large and security-oriented projects. See the response by Drew Crawford.

Does this proposal fit well with the feel and direction of Swift?
File scoping has always seemed like a “C legacy” feature. It encourages large files, which is a problem in MacOS and iOS already. This proposal does nothing to decrease file size and makes file scoping the only way to get private scope. File-based scoping also discourages or at least complicates the development of non file-based and non-textual representations of Swift code

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
C and other macro-assemblers. Isn’t there a better model out there somewhere?

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I read through the proposal, which is pretty straightforward.

···

On Mar 20, 2017, at 5:54 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

The review of SE-0159 "Fix Private Access Levels" begins now and runs through March 27, 2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at


(Howard Lovatt) #20

The review of SE-0159 "Fix Private Access Levels"

What is your evaluation of the proposal?

Great idea too fiddly and fussy for my liking. Preferred the original meaning of private.

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

Probably

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

Yes, keep it simple

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

Yes Swift 1!

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

Have been caught out typing private and then wanting to implement an interfaces methods in an extension.

-- Howard.

···

On 21 Mar 2017, at 10:54 am, Douglas Gregor <dgregor@apple.com> wrote:

Hello Swift community,

The review of SE-0159 "Fix Private Access Levels" begins now and runs through March 27, 2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.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/0159-fix-private-access-levels.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-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce