> On Mar 29, 2016, at 6:04 PM, Dietmar Planitzer via swift-evolution
> <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
