This, I think, is the most persuasive argument available here; it provides a concrete use case to justify why one design is superior to the other. On Sat, Oct 7, 2017 at 10:26 David Hart via swift-evolution < swift-evolution@swift.org> wrote:
> 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 >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
