[swift-evolution] [Proposal] Protected Access Level

[Charles Srstka]

> On May 30, 2016, at 11:23 AM, Tino Heth <2th at gmx.de> wrote:
> 
>> Couldn’t you use the same reasoning to claim there shouldn’t be access control at all? Just add documention on methods you want to mark private telling users of the library not to call them!
> 
> I guess you are making fun, but actually, good old Objective-C messaging works just that way:
> You can call all those dangerous and forbidden private methods easily...
> Writing special comments is just one way to document APIs; having no (official) documentation at all is documentation as well ("don't use this!").
> 
> Most technical limitations can be cracked by skilled hackers (working around "protected" is especially easy), so I really think that (for example) declaring a method "final" says "I don't want this to be changed in a subclass" in the first place, and the compiler error that is triggered when you try to break the limitation is little more but a remainder.
> 
> Enforcing limitations using hacks causes confusion, so I would never use such tricks in production code.

The purpose of access control isn’t really to keep out malicious users, though, it’s to prevent accidental misuse and clarify the interface.

One nice vector for accidental misuse is autocomplete. Even if layoutSubviews() has a great big // DON’T USE!!! in the documentation, it’s possible that someone is trying to remember the name of the API they need to use to tell the OS something needs to update its layout, so they type “layout” into the code editor, and lo and behold! Here’s something called layoutSubviews() that sounds like the sort of thing we want. And so it goes. A protected modifier in the language would prevent things like this.

Charles

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160530/5973d857/attachment.html>