[Review] SE-0169: Improve Interaction Between private Declarations and Extensions

Evolution Announcements
1

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:

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:

Reply text
Other replies
<swift-evolution/process.md at master · apple/swift-evolution · GitHub 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

Thank you,

-Doug

Review Manager

2

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

3

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?

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.

···

On Apr 6, 2017, at 4:10 PM, Douglas Gregor <dgregor@apple.com> wrote:

--
Brent Royal-Gordon
Architechies

4

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

What is your evaluation of the proposal?

Strong +1. This would eliminate most of the need to unnecessarily expose private state to scopes where it doesn’t belong.

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

Very much so. I was surprised and disappointed to find out that private didn’t work this way already when 3 came out.

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

Yes, it’s an important and necessary step.
Swift encourages splitting class implementations into a number of extensions for logical grouping, protocol conformance, etc. Currently, implementing classes this way often requires bumping private members to fileprivate, thereby dangerously exposing them to any other classes in the file.

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

Most languages don’t have this problem because the primary implementation isn’t normally broken into pieces in the same way. I’d argue that the set of declaration + extensions that make up the primary body of the class are together equivalent to a single-body declaration in other languages, and therefore privates should be available to all pieces thereof.

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

Followed the several discussions about file/private access over the last year or two, and contributed to the current one.

···

On Apr 6, 2017, at 6:10 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

5

+1 from me. This will solve the great majority of cases where “fileprivate” is currently needed, and will facilitate the common use case of splitting a type’s implementation into multiple extensions.

My only wish is that it applied to extensions in the same *module*, rather than the same *file*, so that we could use it to break up those obnoxious 3,000-line files that can result from having to squish everything into a single file. Compared to the status quo, however, this is an improvement.

Charles

···

On Apr 6, 2017, at 6:10 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> 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
<https://github.com/apple/swift-evolution/blob/master/process.md#what-goes-into-a-review-1&gt;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

6

What is your evaluation of the proposal?

-1
I don't see how this "breaking" change is better than just reverting SE-025.

SE-169 complicates private by making it even closer to fileprivate. It technically reverts most of the SE-025 functionality.

If this proposal is desired then just out right revert SE-025.

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?

No.

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

Swift 2 and 3

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

Participated in previous discussions.

···

On Apr 6, 2017, at 4:10 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

7

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

8

What is your evaluation of the proposal?

Strong -1. Just rename ‘fileprivate’ to be less annoying.

This proposal will make things even worse than they are currently. We will regret it just as much, if not more than, 0025. As others have mentioned, it is actively harmful:
• It once again changes the meaning of private
• It takes away most of the actual power of private (vs fileprivate). (I was for returning to the simpler Swift 2 access, but when I did use private, I used it to limit access to just a few lines of code. This proposal gets rid of the last ounce of usefulness of ‘private’ for me, and only has the virtue of a less annoying name).
• It is the camel’s nose in the tent for type-based access (people will ask for future versions to be available in the type in the submodule, module, and then public… but we will be unable to give it to them)
• It breaks the same code that 0159 would have broken
• It will be a nightmare to teach/learn

Also, the idea that we should limit the use of ‘fileprivate’ is incorrect. Fileprivate is the best access levels for a lot of cases, it just has an annoying name. Given our constraints, I now believe the only sane choice left to us is to make fileprivate easier to use (as opposed to making private more like it) and to get rid of the cognitive dissonance of having similar names/concepts by renaming ‘fileprivate’ to something like ‘local’. ‘fileprivate’ (whatever it is called) should be the soft-default. ‘private’ should be the one being used explicitly.

We are likely going to have to rename ‘fileprivate’ anyway to work with submodules (that or add another access level), and ‘local’ has connotations of visible nearby… so I think it works well enough.

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

Yes, access controls are a mess… but this will make them more of a mess.

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?

No. I have used languages with type-based private, and I have used languages with file-based private… but never type-based that was limited to a file. You got shrimp in my chocolate (not all great tastes go well together).

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

I have followed the discussion closely and spent a great deal of time thinking about it.

Thanks,
Jon

9

If you don't want to resolve the mistake of SE-0025 by proposing a really solution but not a workaround, then just leave the things where they are currently. Proposed "improvement" IMO is more confusing than helping.

Sorry, I don't buy <<..most of those proposals are not in scope for discussion in Swift 4 (or any later release), given the significant impact on source compatibility>>, because SE-0169 is also a source breaking change, and the problem of access modifiers is important enough to relax the rule of source compatibility for it, *especially if this is the last chance*.
Also, it seems like core team was ready to accept SE-0159(Fix Private Access Levels) which also has impact on source compatibility(given it suggested to remove scoped-private).
IMO SE-0159 + new 'scoped' keyword for scoped-private is the solution we need.

So, -1 from me.

···

On 07.04.2017 2:10, Douglas Gregor via swift-evolution 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

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

10

What is your evaluation of the proposal?

-1. I have been a vocal proponent of scoped access all along. Despite that I really tried to keep an open mind about this proposal. In the end, I just don’t think it is the right decision.

I can see why some people would like to consider a main type declaration and extensions to be considered the same scope when they are in the same file. Extensions of a type within a file are usually used primarily for organizational purposes. The intent often isn’t really to create a scope boundary. Needing to use the slightly verbose `fileprivate` is unfortunate. But the keyword isn’t a scoping problem, it is a naming problem.

I think the most compelling argument in the proposal is the one that says it is important to highlight same-file, cross-type communication using the `fileprivate` keyword. The argument is that by making this the only case where `fileprivate` is used will make these special cross-type members stand out more. I considered this carefully and ultimately concluded that I just don’t think it’s that important.

The reason I put scopes for more than one type in the same file to begin with is that privileged access of one kind or another is necessary. For this reason, I think if we’re going to have a “soft default” that works in the vast majority of cases it should be file scope. It would be nice if file scope could regain the name `private` without losing the scoped access feature but if we just can’t make that happen maybe we’ll just have to live without the “soft default”.

It isn’t cross-type members that I want to stand out. It is same-scope-only members that need to stand out. These members are scoped for important reasons and it is valuable to tightly bound code that can access them and avoid needing to look elsewhere in the same file for accesses. Brent made an eloquent case for this despite having supported the rollback to Swift 2 access levels.

In the end, I still think the name `fileprivate` was a mistake and that the best design is Swift 2 `private` with `scoped` as the name for the Swift 3 `private`. If we’re not going to fix that we should just leave access control alone in Swift 4.

When we’re ready to discuss submodules as part of a release theme I hope we will also be willing to revise access control as a part of that them if that makes sense in the context of whatever submodules end up looking like. At this time we would not only have more context regarding submodules, we would also have the benefit of more time and experience with the current access levels which may be helpful in informing our decision.

In recent threads on this topic there has been some discussion of introducing some kind of organizational mechanism that can be used within the scope of a type declaration. I think this is an interesting approach and is the right approach to explore if we want to have a way to organize a type’s declaration without creating scope boundaries. It would allow people to organize their members while still using `private` more often and better highlighting members that are visible file-wide.

In Objective-C MARK comments were very commonly used for this purpose. In Swift this is still possible but has been mostly replaced with extensions. People want to use an organizational mechanism that is supported by the language. Maybe we need some kind of organizational mechanism that does not create a scope boundary. This is a topic for another discussion, but is worth keeping in mind while considering the merit of the current proposal.

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

No. I believe it makes the language worse, not better. It doesn’t address the real problems with access control. The largest problem is the inability to form scopes between files and the entire module. The problem with `fileprivate` and `private` is a naming problem, not a semantics problem.

I also believe the proposal does not adequately acknowledge the impact on existing code. While most code will still compile the semantics will be significantly different for people who are using scoped access as it was intended - to closely bound access to members when there are good reasons for doing that. In order to maintain semantic compatibility this code will need to be re-written to introduce a new type if there remains a desire to highlight access to these members. Even then, it will be possible to extend that type elsewhere in the file to open a new scope which can access the members.

We no longer have a tight bound, only a way to make it more verbose and obvious when the scope is opened elsewhere in the file. This is a significant, not a small impact on this code. The core team rejected SE-0159 because it determined people are using scoped access control for good reasons. I don’t understand how we could go from that decision to making a change that effictively removes the primary benefit derived from using scoped access.

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

No. It violates the principle of nested scopes that has always been the foundation of Swift’s access control. This principle is a very good one. Any devastation from it should be extremely strongly motivated. This proposal is not. I believe it makes access control more complex, not simpler.

I am sympathetic to those who want to say `private` instead of `fileprivate` to share members between type declarations and same-type extensions in the same file but violating the principle that underlies Swift’s access control is not the right way to solve that problem.

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

No.

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

In-depth study.

11

-1 for reasons I've previously expressed in the discussions:

- It encourages everything to be stuffed in one file.
- It doesn't actually solve anything as the new private is very close to fileprivate, while abolishing private as truly scoped - which is a tool I use on regular basis.

Simply as long as it's file-based, it's not a solution, it's just another attempt to satisfy some part of the community. I'm not saying that the current access levels are perfect, but I still believe the way to go is to either use submodules, and/or introducing the concept of "protected" members.

···

On Apr 7, 2017, at 1:10 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> 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
<https://github.com/apple/swift-evolution/blob/master/process.md#what-goes-into-a-review-1&gt;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

12

+1 this is perhaps the best compromise between the two views on access control I have seen in a while and the change is actually very tiny yet meaningful. Thanks David and Chris!

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?

+1 this is something that would make the language more pleasing to use and easier to learn and code well in.

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

Yes, we have a rare chance to adjust something that represented a pain point and brought lots of arguing back and forth in the community. It is time to move past it and give it the help it needs.

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

I think it does yes.

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

It makes private and fileprivate belong in the language and help it stay true to its progressive disclosure and architecture goals while being more inviting to users coming from other super mainstream programming languages which facilitate the cross pollination of ideas and talent.

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

Followed all the scoped and regular access controls discussions.

···

Sent from my iPhone

On 7 Apr 2017, at 00:10, 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

13

Proposal link:

   - What is your evaluation of the proposal?

Strongly +1, this is definitely a strong step in a good direction, and it

would make Swift more pleasant to work with for the programmers that use
extensions to organize their code.

As I see it by reading the strong opinions about this proposal in the
mailing list, we can split the affected groups into three:

1. Programmers that do not use extensions in the same file to organize
their code.
2. Programmers that use extensions to organize their code but do not care
about sharing implementation details in the same file within a type.
3. Programmers that use extensions to organize their code but care about
sharing implementation details in the same file within a type.

The first bunch is not affected at all by this proposal, no matter the
programmer style that they choose (like spliting extensions in separate
files). They may feel that nothing improves with this, or that some
opportunity is missed by this, or that SE-0025
<https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md&gt;
will
never be reverted if this proposal gets accepted. Nevertheless, this change
do not affect their code at all, even if it pushes the community to other
programming style.

The second bunch, were I live, will receive this change with open arms. We
think that if you are writing in a file you have access to the code in that
file and can see/modify all the usages. It may be too little for some, but
this proposal clearly improves the current situation for this group.

The third bunch are the ones whose code can be hurt, that is clear and I'm
not going to judge their reasons here. I suppose that this group was very
much in favor of the divisive SE-0025
<https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md&gt;\.
But I'm not seeing this group happy with any proposal that does not
includes more granularity, like another scope modifier, and any such
proposal will hurt the first and second groups.

I don't know how big or representatives are these groups, I suppose the
first group will include the majority of newcomers and the second group
will include more seasoned Cocoa programmers, but that is just my
impression.

Also, I like this change very much because the Swift 4 migration will be
painlessly for basically everyone, unlike the Swift 3 fileprivate
migration. No code should be changed if you don't want it, and the code
will keep working the same. The only case where you can have problems
migrating would be if you had:

struct House {
    private func openWindows() {}
}

extension House {
    private func openWindows() {}
}

But that is not even accepted by the compiler right now (at least not in
the Linux one).

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

Yes. This would be the thing that would rush me to upgrade to Swift 4 as
fast as possible, since it would remove the single major painpoint that I
had with Swift syntax.

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

Yes, it encourages again the use of extensions, not that it needed to.

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

Not applicable, I think.

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

Daily experience working with fileprivate in Swift since the first beta of
Swift 3.

···

On Fri, Apr 7, 2017 at 1:10 AM Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote:

--

INNOVATION IN PERSONAL COMMS

*[image: Imágenes integradas 5]*

*Víctor Pimentel Rodríguez · *Principal iOS Engineer
vpimentel@tuenti.com

+34 914 294 039 <javascript:void(0);> — +34 687 840 886
<javascript:void(0);>
C/ Gran Vía, nº 28, 6ª planta — 28013 Madrid
Tuenti Technologies, S.L.

www.tuenti.com

14

What is your evaluation of the proposal?

+1

Is is excellent:

- the private/fileprivate qualifier used not to be a intrinsic property of an object (because one had to move from private to fileprivate as soon as an extension was added). Now private/fileprivate can be made meaningful, and above all *stable*. A scenario where private is turned into a fileprivate now involves something called "friendship" in C++: fileprivate now reflects *actual design intent*, not "shut up this stupid compiler".

- Swift 4 goals about source compatibility have been taken in account by the very skilled proposal authors.

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

Oh yes. We are many to agree that fileprivate was poorly designed, to say the least.

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 access control becomes meaningful again.

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

Come on, did *you* read all messages about SE-0159? ;-)

Good work, and thanks
Gwendal Roué

···

Le 7 avr. 2017 à 01:10, Douglas Gregor via swift-evolution <swift-evolution@swift.org> a écrit :

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

15

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?

Just barely +1.

It is a tough choice on whether this is a good change, because various future proposals which have been discussed would be impacted by the change:

- If we add the ability in the future for extensions in the same type to declare stored properties, this influences the behavior of that feature (in potentially both good and bad ways)
- If we add further access controls above ‘private’ in the future, the weakening of private as strongest access control may affect the cleanliness/completeness of that design.

Unlike the API design guidelines, access control levels don’t seem to have common usage patterns amongst the Swift community, with different desired levels of protection within a module (below ‘internal’). This makes the use of “file private” much more opinionated IMHO - widening private just enough that it might even become a common consideration that use of “fileprivate” is a potential code smell. The need to use “fileprivate” means that details of the implementation of a type may be selectively be exposed to other types, causing higher coupling, causing more code to be placed into a single file, and thus reducing overall maintainability. Similar to the use of IUOs, forced unwrapping and try! , this may still be desirable, and the complexity and impact can be managed appropriately.

So +1 because the decision is being forced for the Swift 4 timeframe, without the ability to evaluate it in scope of a future Swift release that might focus on submodules or extensions with stored properties. Given a crystal ball, i might pick differently.

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

Yes, although I personally don’t like that we are still designing access control incrementally.

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

I feel it fits well with current Swift, but is being forced to be evaluated in a vacuum in terms of future Swift direction.

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

In-depth study

-DW

···

On Apr 6, 2017, at 5:10 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

16

-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 <dgregor@apple.com> 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

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

17

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

18

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?

It pains me to say this: -1. I think this is a bandaid solution.

Swift had a simple module based access control. Was it the right one? Debatable. But at least the story was consistent and it worked. Then Scoped access came along rather than trying to really flesh out the problem of access control, and for some stupid reason, we chose to make private scoped and introduce a terrible access modifier for what was "private" before.

We don't have submodules yet. When they come, we need to flesh this stuff out, and deal with concepts like "protected" ect rather than ignoring them like we seem to be doing.

I think reverting the behaviour (in the previous proposal) was right short term, but not long term, and created unnecessary churn. But the fight for Swift source stability needs to take a back seat to getting this right in the Swift 5 timeline and we need to accept that some level of pain will come because we need to rework this stuff to get it right for the future.

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

Yes. We need to sort out access control. The current solution seems ill equipped for the future.

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

No. It is a bandaid solution which confuses the point of 'private'. Is it scoped, or a weird mid-way between a scoped and fileprivate?

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

Some with access control, and our system seems broken.

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

Quick reading.

···

On 7 Apr 2017, at 9:10 am, 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

19

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 <dgregor@apple.com> 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?

20

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

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

Strong -1.

While I've been strongly against the existence of Swift 3 "private", the
fact is that scoped private is here to stay. If I set my personal biases
aside and look at what this proposal does to scoped private, it muddies the
definition of "private" to the point that it's very confusing.

To describe what I mean, the great thing about Swift 2 visibility was that
it was dead simple to explain what each visibility level applied to:

- public: visible to everyone
- internal: visible in the same module
- private: visible in the same file

Even Swift 3 visibility, with scoped private, has this property:

- public: visible to everyone
- internal: visible in the same module
- fileprivate: visible in the same file
- private: visible in the same scope

Notice that the concept of "type" is nowhere in those definitions. Each
visibility level is based on contiguous physical barriers: the world, the
module, the file, a region bounded by curly braces within a file. But this
change would make the definition of "private" a lot more confusing:

- private: visible in the same scope and extensions to the same type but
only if those extensions are in the same file

It's *much* harder to explain what this "private" means. Does it apply to
scopes? No, it can span scopes because of extensions in the same file. Does
it apply to the same file? No, scopes outside the containing type and its
extensions can't use it. Does it apply to the same type? No, extensions to
the type outside of the containing file can't use it. This "private" is a
hodge-podge of different semantics.

It feels to me that the purpose of this proposal is for people to avoid
typing "fileprivate" which they believe to be ugly. I also think it's ugly,
but I don't want to break the language's visibility model to avoid it.
Furthermore, if the core team's position is that scoped private is valuable
enough and used by enough people that it's worth keeping, then this
proposal unravels it.

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

No. Until there's a significant need to revisit it (i.e., submodules), we

need to accept that a line has to be drawn *somewhere* with regard to
visibility, and not everyone is going to be 100% happy. It's time to move
on.

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

No, for the reasons mentioned above (the consistency/contiguity of

visibility regions).

···

On Thu, Apr 6, 2017 at 4:10 PM Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote:

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

Participation in earlier discussions and a reading of this proposal.

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