<div dir="ltr">That's the key point.<div><br></div><div>"Protected" would increase the expressivity of the language by declaring intent and exposing cleaner public APIs.</div><div><br></div><div>I don't think this idea should be dropped just because <span style="font-size:12.8px">conscious</span> hacks/decisions can workaround it, so big +1 for it.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-03-30 5:51 GMT+01:00 Thorsten Seitz via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
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.<br>
<br>
Having said that I'd love to have "protected".<br>
<br>
-Thorsten<br>
<div class="HOEnZb"><div class="h5"><br>
> Am 30.03.2016 um 03:28 schrieb Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br>
><br>
><br>
>>> On Mar 29, 2016, at 6:18 PM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>>><br>
>>><br>
>>> On Mar 29, 2016, at 6:04 PM, Dietmar Planitzer via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>>><br>
>>> Well that would be true if we assume that protected would work that way. Considering that this:<br>
>>><br>
>>> private class A { … }<br>
>>><br>
>>> public class B : A { … }<br>
>>><br>
>>> 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:<br>
>>><br>
>>> public class A {<br>
>>> private func foo() {<br>
>>> print("A")<br>
>>> }<br>
>>> }<br>
>>><br>
>>> public class B : A {<br>
>>> public override func foo() {<br>
>>> print(“B”)<br>
>>> }<br>
>>> }<br>
>>><br>
>>> 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.<br>
>><br>
>> That would still be a toothless restriction, since a subclass could define a new method:<br>
>><br>
>> public class B : A {<br>
>> public func foo_() {<br>
>> super.foo()<br>
>> }<br>
>> }<br>
>><br>
>> 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.<br>
><br>
> 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.<br>
><br>
> -Joe<br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>