> On Mar 21, 2017, at 4:26 PM, Jose Cheyo Jimenez <[email protected]> wrote: > > >> On Mar 21, 2017, at 11:54 AM, Matthew Johnson via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> >>> On Mar 21, 2017, at 1:41 PM, David Hart via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> >>> >>> >>> >>> Sent from my iPhone >>> On 21 Mar 2017, at 16:57, Drew Crawford <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>>> >>>> >>>>> > I’m not arguing that it is less or more than a majority. I’m just >>>>> > saying that we’ve seen a lot of talk against the original change. >>>> >>>> This proposal asks us to balance the convenience of one group >>>> (extension-writers) against the existence of another (scoped-access >>>> users). To do that, we need a clear idea of the composition of both >>>> groups. >>>> >>>> “A lot of talk” is not the evidentiary standard to remove a feature. It >>>> was not good enough when we introduced the feature, that required argument >>>> and clear use-cases. >>>> >>> "A lot of talk" is not the evidence supporting the proposal: it's just a >>> warning that something may be very controversial among the community. The >>> arguments for the revert are in the proposal and in the discussions in this >>> thread. >>> >>>>> > By default, I did not mean the syntactic default of the language but >>>>> > the access modifier users will use “by default” when trying to restrict >>>>> > visibility. In most languages, that keyword is “private” so its valid >>>>> > to say that newcomers to the language will “default” to using that one. >>>> >>>> Apologies, but I do not understand the argument: >>>> >>>> A user wants to restrict visibility (e.g. they are dissatisfied with >>>> “internal”) >>>> The user *chooses* private because of familiarity from another language >>>> The user is then surprised that their choice of private indeed restricted >>>> the visibility, thus achieving their goal? >>>> What language does the user come from in which “private” is file-visible? >>>> It isn’t Java, C++, or PHP. C#’s “partial” is the closest I can think of, >>>> and it isn’t at all close. >>> >>> It has pointed quite a few times by core team members that comparison to >>> languages is not a very strong arguments, especially when Swift does things >>> differently for a good reason. I can't stop from quoting Xiaodi from a >>> month back: >>> >>> «The beauty of Swift 2's access modifiers was that they were based around >>> files and modules, explicitly rejecting types and scopes as units for >>> determining visibility.» -- Xiaodi >>> >>>> A user who wants a middle-ground visibility would “default” to >>>> “protected”, “friend”, “partial”, or similar. After that does not >>>> compile, they will use google to find a middle-road visibility keyword, >>>> for which the only candidate is “fileprivate”. But they will not choose >>>> “private”, it’s just not a reasonable expectation of what the keyword >>>> means to a new Swift developer. >>>> >>>> The popularity of private “as a default” is simply because many users >>>> prefer to hide their implementation details as a matter of routine code >>>> hygiene. Redefining private in order to thwart their code hygiene goal >>>> seems extreme. >>> >>> The point is that keeping both private and fileprivate feels like an >>> un-necessary complication: >>> >>> • either a programmer falls on your side of the fence and will use private >>> as often as possible and relegate to fileprivate when the design leaves no >>> other choice. At that point it feels like a language wart. >>> • or a programmer will fall on my side of the fence and use fileprivate all >>> the time and the language feels like it has an unnecessary access modifier. >>> >>> I'd argue that the cases when a programmer will use both meaningfully is >>> very rare. As a consequence, we should try to only keep one. Removing >>> fileprivate is a no-go with extensions so that leaves us with removing >>> private. >> >> Removing scoped access is a no-go if we consider tightly encapsulating >> invariant-preserving state to be an important feature. The fact is that >> both features can be used meaningfully. The fact that some people choose >> not to do this is not an argument against the features being available. It >> is an opportunity to encourage people to thing more carefully about why they >> are encapsulating something. > > I understand the bigger picture you are getting at but the scope access you > have envisioned should not be called private.
I don’t disagree with this. I’m fine with renaming it and allowing `private` to mean file-level scope. > > In order to get scope access to a place where it is more useful we have to > remove it. No we don’t. We could remove it and re-add it but that would be crazy. We would break a bunch of code that doesn’t need to break if we’re going to keep the feature under a new name. > > I don’t mind if scope access is kept but it must have a different name and > that should be a different limited scope proposal. > > Opposing SE-0159 will make it much harder to redefine scope access. I disagree. It just maintains the status quo until the core team is ready to take up access control and submodules as a theme of a future release. At that time we could revisit this feature area holistically. > > >> >> A programmer has to make a conscious decision to give a declaration >> visibility other than internal. If they have trouble identifying whether >> file or scoped access is appropriate this indicates they don’t really >> understand their intent in encapsulating the declaration very clearly. I >> don’t think it’s a bad thing to ask people to think about this a little bit >> more. A simple guideline is to use file-level access unless you have a >> specific reason for preferring the tight encapsulation scoped access >> provides. Both Drew and I have offered some examples of specific reasons >> for using scoped access that IMO are important enough that they deserve to >> be supported by the language. >> >>> >>>> I agree with several here (as I did in SE-0025) that our access modifiers >>>> are not well-named. However, that’s not the proposal in front of us. >>>> >>>>> > My own statistics in my projects show the contrary. At best, this shows >>>>> > how divisive this feature is. >>>> >>>> This *may* show that, if contrary statistics were presented, but that >>>> hasn’t occurred. >>>> >>> I can generate statistics from my projects if you want. But it's >>> unnecessary: I haven't used private once since it's introduction in Swift >>> 3. I don't see the advantages it brings worth the trouble. >>>>> In old code, statistics could be biased by the migrator having replaced >>>>> all previous instances of private by fileprivate. >>>> >>>> If the migrator migrated code to private, and it *worked* (e.g. did not >>>> introduce visibility errors) this is not bias, this is a correct use of >>>> the feature. >>>> >>> The migrator migrated to fileprivate everywhere, not private, disagreeing >>> with your use of fileprivate. >>> >>>>> > I'm just arguing that the additional scope-based access modifier does >>>>> > not provide enough differentiation to be worth that complexity. >>>> >>>> The only argument I have seen so far around “complexity” boils down to: >>>> “some people do not use it”. But some people *do* use it, and anyway if >>>> we are going to remove all the features “not enough people” use then we >>>> are in for a ride. >>>> >>> Some people used the for(;;) loop, the ++ operator, var parameters. Many >>> other features were removed from Swift to simplify he language, make it >>> more consistent. Those are worthwhile goals. Yes, we are past Swift 3 now, >>> but that doesn't mean we shouldn't be able to propose a few rare breaking >>> proposals. The implementation of access modifiers came so late in the Swift >>> 3 timeframe that we had little time to play around with them before Swift 3 >>> was released. Now that we have, we have a short window of time to fix >>> mistakes that were made. I'm just arguing that the proposal was one of >>> those mistakes. But you have a right to disagree. >>>> Swift 3 shipped, so what we are discussing now is yanking a keyword >>>> without replacement. There is code written that uses private to enforce >>>> its threading or security invariants. There is code written that uses >>>> private in order to shadow another declaration. There is code that will >>>> not compile after migration. We need more than a vague fear of complexity >>>> generally to throw a brick through all those windows. That brick will >>>> introduce quite a bit of complexity itself. >>>> >>>>> 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. >>>> >>>> The form of the argument is invalid. Suppose I argued: "it’s a good thing >>>> for the language to encourage one definition per class (no extensions), >>>> it’s good practice. So we do not need fileprivate.” That would be very >>>> silly (although it has already been advanced as a straw-man position >>>> elsewhere in this thread). The argument that we do not need private >>>> because nobody should put multiple classes in a file is equally silly. >>>> There are reasons to do so, in fact one motivation was given in SE-0025: >>>> >>>>> > 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. >>>> >>>> >>>> These concerns are not resolved by arguments of the form “just don’t do >>>> that”. >>>> >>>> I empathize with the Swift2 programmer who got through two releases >>>> without a scoped access modifier and is annoyed by change. However, >>>> removing the feature now is more change, not less, so it makes their >>>> problem worse, not better. >>>> >>>> >>>> On March 21, 2017 at 2:17:40 AM, David Hart ([email protected] >>>> <mailto:[email protected]>) wrote: >>>> >>>>> Perhaps it was a mistake, but I purposefully did not go into too much >>>>> detail in the proposal because I think this debate is purely a question >>>>> of philosophy on Swift and its language features. I did not want to add >>>>> un-necessary bloat that would have added little rationalisation. Let me >>>>> try to explain the holes in the proposal by answering your review: >>>>> >>>>>> On 21 Mar 2017, at 02:26, Drew Crawford via swift-evolution >>>>>> <[email protected] <mailto:[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? >>>>> It’s not feasible to measure precisely the feeling of a whole community. >>>>> But we get a feeling for it by following the mailing-list, by talking to >>>>> colleagues, by reading twitter, etc… And it think we all agree that the >>>>> debate is highly divisive and that a “substantial proportion” of the >>>>> community was dissatisfied: I’m not arguing that it is less or more than >>>>> a majority. I’m just saying that we’ve seen a lot of talk against the >>>>> original change. >>>>>> What was done to control for the population happy with SE-0025 who would >>>>>> e.g. not be likely to take up pitchforks? >>>>> That’s why its important we have this debate now. >>>>>> Who argues these changes are “actively harmful” and where were they >>>>>> during SE-0025? >>>>> The proposal makes the argument that the changes are actively harmful. >>>>> It’s now up to debate. By the way, even if several people (including me) >>>>> were already against this proposal during the review, I don’t see why >>>>> anybody would not have the right to change his mind, especially after >>>>> several months of production usage and argue differently now. >>>>>> > 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. >>>>> By default, I did not mean the syntactic default of the language but the >>>>> access modifier users will use “by default” when trying to restrict >>>>> visibility. In most languages, that keyword is “private” so its valid to >>>>> say that newcomers to the language will “default” to using that one. If >>>>> the proposal is accepted, file-scoped private will regain that status. >>>>>> > 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 >>>>>> <https://code.sealedabstract.com/drewcrawford/NaOH> | 15 | 1 >>>>>> | 15x | >>>>>> >>>>>> | atbuild https://github.com/AnarchyTools/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. >>>>>> >>>>> My own statistics in my projects show the contrary. At best, this shows >>>>> how divisive this feature is. During the discussion of this proposal, it >>>>> was argued that making decisions based upon project statistics would be >>>>> dangerous: >>>>> >>>>> In old code, statistics could be biased by the migrator having replaced >>>>> all previous instances of private by fileprivate. >>>>> In new code, satistics could be biased by people using private because of >>>>> it being the “soft-default”, regardless of proper semantics. >>>>>> > 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? >>>>>> >>>>> Sorry if I did not state it explicitly, but I see any feature/keyword >>>>> added to the language as “additional complexity”. And that complexity is >>>>> completely worth it when the feature adds significant expressivity. I'm >>>>> just arguing that the additional scope-based access modifier does not >>>>> provide enough differentiation to be worth that complexity. >>>>>> 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 >>>>>> <https://code.sealedabstract.com/drewcrawford/NaOH> | 15 | 1 >>>>>> | 15x | 3 | >>>>>> >>>>>> | atbuild https://github.com/AnarchyTools/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. >>>>>> >>>>> I agree that different people in different corners use different styles. >>>>> But you could use that argument to validate many features which would >>>>> make a group of users happy; but all those feature together would just >>>>> add bloat to the language. Swift has been known to be a very opinionated >>>>> language, to keep the language simple yet expressive. >>>>>> 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] >>>>>> <mailto:[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 >>>>>> >>>>>> <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 >>>>>> <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 >>>>>> >>>>>> <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 >>>>>> <https://github.com/apple/swift-evolution/blob/master/process.md> Thank >>>>>> you, >>>>>> >>>>>> -Doug >>>>>> >>>>>> Review Manager >>>>>> >>>>>> swift-evolution-announce mailing list [email protected] >>>>>> <mailto:[email protected]> >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce >>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution-announce>_______________________________________________ >>>>>> swift-evolution mailing list >>>>>> [email protected] <mailto:[email protected]> >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
