<html><head><style>
body {
font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
padding:1em;
margin:auto;
background:#fefefe;
}
h1, h2, h3, h4, h5, h6 {
font-weight: bold;
}
h1 {
color: #000000;
font-size: 28pt;
}
h2 {
border-bottom: 1px solid #CCCCCC;
color: #000000;
font-size: 24px;
}
h3 {
font-size: 18px;
}
h4 {
font-size: 16px;
}
h5 {
font-size: 14px;
}
h6 {
color: #777777;
background-color: inherit;
font-size: 14px;
}
hr {
height: 0.2em;
border: 0;
color: #CCCCCC;
background-color: #CCCCCC;
display: inherit;
}
p, blockquote, ul, ol, dl, li, table, pre {
margin: 15px 0;
}
a, a:visited {
color: #4183C4;
background-color: inherit;
text-decoration: none;
}
#message {
border-radius: 6px;
border: 1px solid #ccc;
display:block;
width:100%;
height:60px;
margin:6px 0px;
}
button, #ws {
font-size: 12 pt;
padding: 4px 6px;
border-radius: 5px;
border: 1px solid #bbb;
background-color: #eee;
}
code, pre, #ws, #message {
font-family: Monaco;
font-size: 10pt;
border-radius: 3px;
background-color: #F8F8F8;
color: inherit;
}
code {
border: 1px solid #EAEAEA;
margin: 0 2px;
padding: 0 5px;
}
pre {
border: 1px solid #CCCCCC;
overflow: auto;
padding: 4px 8px;
}
pre > code {
border: 0;
margin: 0;
padding: 0;
}
#ws { background-color: #f8f8f8; }
.bloop_markdown table {
border-collapse: collapse;
font-family: Helvetica, arial, freesans, clean, sans-serif;
color: rgb(51, 51, 51);
font-size: 15px; line-height: 25px;
padding: 0; }
.bloop_markdown table tr {
border-top: 1px solid #cccccc;
background-color: white;
margin: 0;
padding: 0; }
.bloop_markdown table tr:nth-child(2n) {
background-color: #f8f8f8; }
.bloop_markdown table tr th {
font-weight: bold;
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr td {
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr th :first-child, table tr td :first-child {
margin-top: 0; }
.bloop_markdown table tr th :last-child, table tr td :last-child {
margin-bottom: 0; }
.bloop_markdown blockquote{
border-left: 4px solid #dddddd;
padding: 0 15px;
color: #777777; }
blockquote > :first-child {
margin-top: 0; }
blockquote > :last-child {
margin-bottom: 0; }
code, pre, #ws, #message {
word-break: normal;
word-wrap: normal;
}
hr {
display: inherit;
}
.bloop_markdown :first-child {
-webkit-margin-before: 0;
}
code, pre, #ws, #message {
font-family: Menlo, Consolas, Liberation Mono, Courier, monospace;
}
.send { color:#77bb77; }
.server { color:#7799bb; }
.error { color:#AA0000; }</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><p>I disagree quite strongly with the proposal.</p>
<p>First, the document draws conclusions without apparent supporting evidence, e.g.</p>
<blockquote>
<p>> 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.</p>
</blockquote>
<ul>
<li>What is “dissatisfaction by a substantial proportion of the general Swift community”? How was this measured/determined?</li><li>What was done to control for the population happy with SE-0025 who would e.g. not be likely to take up pitchforks?</li>
<li>Who argues these changes are “actively harmful” and where were they during SE-0025?</li>
</ul>
<blockquote>
<p>> subtly encourages overuse of scoped access control and discourages the more reasonable default</p>
</blockquote>
<ul>
<li>Who claims that scoped access is “overused” and what is their argument for doing so?</li>
<li>Why is “fileprivate” the “more reasonable default”? In fact neither fileprivate *<em>nor*</em> 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.</li>
</ul>
<blockquote>
<p>> But is that distinction between private and fileprivate actively used by the larger community of Swift developers?</p>
</blockquote>
<p>Yes. To cite some evidence, here are codebases I actively maintain:</p><p><font face="Courier New">| codebase | private # | fileprivate # | ratio |</font></p><p><font face="Courier New">|--------------------------------------------------------|-----------|---------------|-------|</font></p><p><font face="Courier New">| "M" (proprietary) | 486 | 249 | 2x |</font></p><p><font face="Courier New">| "N"(proprietary) | 179 | 59 | 3x |</font></p><p><font face="Courier New">| NaOH https://code.sealedabstract.com/drewcrawford/NaOH | 15 | 1 | 15x |</font></p><p><font face="Courier New">| atbuild https://github.com/AnarchyTools/atbuild | 54 | 5 | 11x |</font></p>
<p>So from my chair, not only is the distinction useful, but scoped access control (private) is overwhelmingly (2-15x) more useful than fileprivate.</p><p>> 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</p><p>This proposal does not make any later argument about “cognitive load” or “complexity” I can identify. Did the proposal get truncated?</p><p>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</p><p><font face="Courier New">| codebase | private # | fileprivate # | ratio | # of extensions (>=3 extensions in file) |</font></p><p><font face="Courier New">|--------------------------------------------------------|-----------|---------------|-------|------------------------------------------|</font></p><p><font face="Courier New">| "M" (proprietary) | 486 | 249 | 2x | 48 |</font></p><p><font face="Courier New">| "N"(proprietary) | 179 | 59 | 3x | 84 |</font></p><p><font face="Courier New">| NaOH https://code.sealedabstract.com/drewcrawford/NaOH | 15 | 1 | 15x | 3 |</font></p><p><font face="Courier New">| atbuild https://github.com/AnarchyTools/atbuild | 54 | 5 | 11x | 6 |</font></p><p>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.</p><p>My point here is that <b>**different people in different corners of the community program Swift differently and use different styles**</b>. 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.</p><p>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.</p><p>Finally, SE-0025 establishes clear motivation for the scoped access modifier:</p><p>> 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:</p><p>> 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.</p><p>> 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.</p><p>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.</p><p>Drew</p><p>On March 20, 2017 at 6:54:55 PM, Douglas Gregor (dgregor@apple.com) wrote:</p>
<p>Hello Swift community,</p>
<p>The review of SE–0159 “Fix Private Access Levels” begins now and runs through March 27, 2017. The proposal is available here:</p>
<p>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</p>
<p>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:</p>
<p>Proposal link:</p>
<p>https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
Reply text
Other replies
What goes into a review?</p>
<p>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:</p>
<p>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</p>
<p>https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,</p>
<p>-Doug</p>
<p>Review Manager</p>
<hr>
<p>swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce</p></body></html>