> On 21 Mar 2017, at 02:26, Drew Crawford via swift-evolution > <swift-evolution@swift.org> 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. > Concerning the one-class-per-file argument, I would suggest this counter-argument: when working in large projects, I believe it's a good thing if the language encourages (forces is too strong a word for my taste) a one class per file structure, it's good practice. And in small projects, which can hold in a file or two, I don't think that scope-based private provides a worthwhile distinction. > 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 (dgre...@apple.com) 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 swift-evolution-annou...@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution-announce > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
