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 ([email protected]) 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 [email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution-announce
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
