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

[Joe Groff]

> 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.

-Joe