[swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

[David Hart]

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 at swift.org> wrote:
> 
> 
>> On Oct 6, 2017, at 9:35 PM, Tony Allevato <tony.allevato at gmail.com> wrote:
>> 
>> 
>> 
>> On Fri, Oct 6, 2017 at 9:29 PM Jose Cheyo Jimenez <cheyo at masters3d.com> wrote:
>>>> On Oct 6, 2017, at 8:58 PM, Tony Allevato <tony.allevato at gmail.com> wrote:
>>>> 
>>>> 
>>>> 
>>>> On Fri, Oct 6, 2017 at 8:45 PM Jose Cheyo Jimenez <cheyo at masters3d.com> wrote:
>>>>>>> On Oct 6, 2017, at 8:01 PM, Tony Allevato <tony.allevato at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171007/98869164/attachment-0001.html>