-1 I second Drew Crawford's 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.
On 21 March 2017 at 06:56, Drew Crawford via swift-evolution < [email protected]> wrote: > 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 > > -- *Pranshu Goyal* *iOS Developer* *tlkn*
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
