<div dir="ltr">-1<div><br><div>I second <span style="font-size:12.8px;font-weight:bold;white-space:nowrap">Drew Crawford's </span>opinion. Although I agree with some of the critiques about the current state of access levels in swift, I don't believe that this would be the right way to proceed.</div><div><div class="gmail_extra"><br><div class="gmail_quote">On 21 March 2017 at 06:56, Drew Crawford via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><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">|-----------------------------<wbr>---------------------------|--<wbr>---------|---------------|----<wbr>---|</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 <a href="https://code.sealedabstract.com/drewcrawford/NaOH" target="_blank">https://code.sealedabstract.<wbr>com/drewcrawford/NaOH</a> | 15 | 1 | 15x |</font></p><p><font face="Courier New">| atbuild <a href="https://github.com/AnarchyTools/atbuild" target="_blank">https://github.com/<wbr>AnarchyTools/atbuild</a> | 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">|-----------------------------<wbr>---------------------------|--<wbr>---------|---------------|----<wbr>---|--------------------------<wbr>----------------|</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 <a href="https://code.sealedabstract.com/drewcrawford/NaOH" target="_blank">https://code.sealedabstract.<wbr>com/drewcrawford/NaOH</a> | 15 | 1 | 15x | 3 |</font></p><p><font face="Courier New">| atbuild <a href="https://github.com/AnarchyTools/atbuild" target="_blank">https://github.com/<wbr>AnarchyTools/atbuild</a> | 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><span class="gmail-"><p>On March 20, 2017 at 6:54:55 PM, Douglas Gregor (<a href="mailto:dgregor@apple.com" target="_blank">dgregor@apple.com</a>) wrote:</p>
<p>Hello Swift community,</p>
</span><p>The review of SE–0159 “Fix Private Access Levels” begins now and runs through March 27, 2017. The proposal is available here:</p><span class="gmail-">
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md" target="_blank">https://github.com/apple/<wbr>swift-evolution/blob/master/<wbr>proposals/0159-fix-private-<wbr>access-levels.md</a>
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at</p>
<p><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a>
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><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md" target="_blank">https://github.com/apple/<wbr>swift-evolution/blob/master/<wbr>proposals/0159-fix-private-<wbr>access-levels.md</a>
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><a href="https://github.com/apple/swift-evolution/blob/master/process.md" target="_blank">https://github.com/apple/<wbr>swift-evolution/blob/master/<wbr>process.md</a>
Thank you,</p>
<p>-Doug</p>
<p>Review Manager</p>
</span><hr><span class="gmail-">
<p>swift-evolution-announce mailing list
<a href="mailto:swift-evolution-announce@swift.org" target="_blank">swift-evolution-announce@<wbr>swift.org</a>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution-announce" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution-announce</a></p></span></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><font color="#999999" size="2" face="georgia, serif"><i>Pranshu Goyal</i></font><div><font color="#999999" size="2" face="times new roman, serif"><i>iOS Developer</i></font></div><div><font color="#999999" size="2" face="times new roman, serif"><i>tlkn</i></font></div></div></div>
</div></div></div></div>