[swift-evolution] Protected access level / multiple class/struct/protocol APIs

[Joe Groff]

> On Mar 29, 2016, at 6:18 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On Mar 29, 2016, at 6:04 PM, Dietmar Planitzer via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Well that would be true if we assume that protected would work that way. Considering that this:
>> 
>> private class A { … }
>> 
>> public class B : A { … }
>> 
>> is not allowed in Swift, I don’t see a good reason why an override of a protected method should be allowed to upgrade the access level to public. On the other hand this:
>> 
>> public class A {
>>   private func foo() {
>>       print("A")
>>   }
>> }
>> 
>> public class B : A {
>>   public override func foo() {
>>       print(“B”)
>>   }
>> }
>> 
>> happens to actually work if both A and B are defined in the same file - which is rather unexpected. I would have expected that Swift would in general not allow overrides to upgrade the inherited access level. Eg exposing semantics which is embodied in a private or protected method should require a conscisous design decision and should require the designer to introduce a separate method name which is part of the public API. The public method can then call through to the private or protected method as needed.
> 
> That would still be a toothless restriction, since a subclass could define a new method:
> 
> public class B : A {
>   public func foo_() {
>       super.foo()
>   }
> }
> 
> From an interface perspective, there's no difference between a subclass defining a new method or overriding a method that happens to be private to the base class.

Extensions further dilute the enforceability of "protected", since anyone would be able to use an extension to dump methods into a class's namespace and access its supposedly-protected bits.

-Joe