> 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
> <mailto:ch...@masters3d.com>> wrote:
>> On Oct 6, 2017, at 8:01 PM, Tony Allevato <tony.allev...@gmail.com
>> <mailto: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.
>
> 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
