One argument: without this fix, private is the only access level for which we have no means to easily and implicitly apply an access level to a group of members. And it bums me to have to explicitly type private on ever single member to achieve the same result as I can with any other access level.
> On 7 Oct 2017, at 07:07, Jose Cheyo Jimenez via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Oct 6, 2017, at 9:35 PM, Tony Allevato <tony.allev...@gmail.com> wrote: >> >> >> >> On Fri, Oct 6, 2017 at 9:29 PM Jose Cheyo Jimenez <ch...@masters3d.com> >> wrote: >>>> On Oct 6, 2017, at 8:58 PM, Tony Allevato <tony.allev...@gmail.com> wrote: >>>> >>>> >>>> >>>> On Fri, Oct 6, 2017 at 8:45 PM Jose Cheyo Jimenez <ch...@masters3d.com> >>>> wrote: >>>>>>> On Oct 6, 2017, at 8:01 PM, Tony Allevato <tony.allev...@gmail.com> >>>>>>> wrote: >>>>>> At the time SE-0025 was accepted, "private extension" would have been >>>>>> meaningless if it did not mean "fileprivate" because it predated the >>>>>> SE-0169 behavior extending "private" to extensions in the same file. The >>>>>> very issue being debated here is whether the oversight that SE-0169 did >>>>>> not consider extensions—now that "private extension" *could* have a >>>>>> meaningful use separate from "fileprivate extension"—is something that >>>>>> is worth correcting. >>>>>> >>>>>> If the documentation is out-of-date and needs to be updated to list >>>>>> describe unintuitive special behavior, why not use the opportunity to >>>>>> make the behavior intuitive and consistent instead? >>>>> >>>>> Lets say you “fix” the private extension override. Now MyClass2.myFunc2() >>>>> is not accessible from outside the type. >>>>> Wouldn't MyClass2.myFunc2() now be inconsistent with MyClass.myFunc()? >>>>> I don’t think you can make a change to one with out causing other >>>>> inconsistencies. I rest my case. :) >>>> >>>> No, because a class is a concrete "thing" whose access level which—while >>>> providing an upper bound for access levels of its defaulting members—is >>>> otherwise independent of the access level of its members. >>>> >>>> Extensions, on the other hand, aren't a concrete thing of their own. The >>>> access level on an extension exists *solely* as a shortcut to specify the >>>> upper bound for its defaulting members that are injected into the main >>>> type. >>>> >>>> What happens in your example if you replace "private" with "public"? Then >>>> myFunc has internal access but myFunc2 is public. So the "inconsistency" >>>> you're pointing out between access inherited from a type and access >>>> inherited from an extension already exists—they're apples and oranges. >>>> >>>> That's why access levels of classes/structs/other types aren't relevant >>>> examples here—extensions treat access levels fundamentally differently. >>> >>> Sure. Extensions apply a default upper bound and types can lower the upper >>> bound of the default internal members. The upper bound on the below example >>> is the same for both when dealing with top level private. >>> >>> Extensions should resolve their upper bound accessibility where the >>> ‘private’ appears explicitly and this now happens to be the same for both >>> types and extensions regardless of how they are enforced. >> >> But *why* do you think that should be? You're stating what the current >> situation is and you say that it "should" be that way, but why should we >> accept that status quo instead of making "private extension" more useful for >> people who use "private" in the sense introduced by SE-0169, when the >> argument for consistency can honestly be argued either way (the two options >> I wrote a few messages up)? > > Oh :) Because I believe that lowering the scope of “private extension” would > undermine the spirit of 169. 169 was a compromise after 159 was rejected. > 169 was meant to make fileprivate less common and thus more meaningful when > it occurs in source. Where 169 was meant to relax the rules, the proposed > “fix” would force people who now use “private extension” to use “fileprivate > extension” thus making fileprivate more common. In other words, 169 was about > relaxing rules and not about tightening down the rules or allowing “true” > private to be applied as a default ACL extension. > > “scoped" `private extension` can’t be archived now in the same way that ‘open > extension’ is not allowed. The lowest and highest ACL are not able to be > applied as default extension modifiers and this makes sense to me. > > There is no solution that will make everyone happy: maintaining the status > quo makes “fileprivate” too common and therefore not meaningful when it > occurs in source; removing or diluting scope-level access control (as in > SE-0159 > <https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md> > and this proposal) > https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000357.html > > > >> >> >>>>> >>>>> private class MyClass { >>>>> static func myFunc(){ // This would now act differently from private >>>>> extensions? >>>>> print("acts like fileprivate now") >>>>> } >>>>> } >>>>> >>>>> private class MyClass2 {} >>>>> >>>>> private extension MyClass2{ >>>>> static func myFunc2(){ >>>>> print("Same as MyClass.myFunc") >>>>> } >>>>> } >>>>> >>>>> >>>>> MyClass.myFunc() // acts like fileprivate >>>>> MyClass2.myFunc2() // The proposed change would hide myFunc2 >>>>> //Error: 'myFunc2' is inaccessible due to 'private' >>>>> protection level > > _______________________________________________ > 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
