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

[Xiaodi Wu]

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 at 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 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
>
> _______________________________________________
> 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/ff3f7afe/attachment.html>