That's the key point. "Protected" would increase the expressivity of the language by declaring intent and exposing cleaner public APIs.
I don't think this idea should be dropped just because conscious hacks/decisions can workaround it, so big +1 for it. 2016-03-30 5:51 GMT+01:00 Thorsten Seitz via swift-evolution < [email protected]>: > I have no problems with "protected" members being made accessible in > subclasses or extensions because this requires conscious decisions and > actions to extend the API. > Access levels are not there to protect against hacking, they are there to > ensure that something can only be used through its given API. They are not > there to restrict extending that API. > > Having said that I'd love to have "protected". > > -Thorsten > > > Am 30.03.2016 um 03:28 schrieb Joe Groff via swift-evolution < > [email protected]>: > > > > > >>> On Mar 29, 2016, at 6:18 PM, Joe Groff via swift-evolution < > [email protected]> wrote: > >>> > >>> > >>> 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. > > > > 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 > > _______________________________________________ > > swift-evolution mailing list > > [email protected] > > https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
