The problem with protected is that it provides virtually no protection at all; you can trivially expose it in a derived 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.
I don’t understand the need to protect against exposing something deliberately. We don’t have a goal of restricting other developers, we’re only saving them from accidental mistakes.
Totally agree, access control is not intended to be protection against hacking. If a derived class wants to expose something then that is absolutely fine as long as it makes sense for the derived class.
If a method was marked private in the base class, then it is very likely that the name of the method, the design of its argument list and its return value did not go through the same detailed design review as if the method would have been meant to be part of the class’ interface from the start. So it’s rather unlikely that increasing the visibility in an override is good idea and in the spirit of the original writer of the private method.
The design review and whether something is a good idea is left as a responsibility for those subclasses that choose to expose methods. The intentions of the original class author don’t override the intentions of the subclass author.
Am 31. März 2016 um 05:15 schrieb Andrey Tarantsov via swift-evolution firstname.lastname@example.org: