[swift-evolution] classprivate protection level?

[Adam Kemp]

> On Oct 30, 2017, at 10:57 AM, Mike Kluev <mike.kluev at gmail.com> wrote:
> 
> On 30 October 2017 at 17:22, Adam Kemp <adam_kemp at apple.com <mailto:adam_kemp at apple.com>> wrote:
> 
> The goal isn’t to entirely avoid having to audit any code while making a change. The goal is to allow you to reason about which code you would have to audit. A new access level should lead to a new bucket of code that needs to be audited, but none of the proposals here would do that. They’re all equivalent to existing access levels.
> 
> the new bucket would be "class and all of its extensions be them in the same file or in different files”.

That’s not a new bucket. It is equivalent to either internal or public, depending on whether you want to extend this beyond the module boundary. The set of code you would have to audit is the same.

> 
> back to your example with the locked door and the keys on the doorstep, i can violate "protected" in C++:
> 
> developer 1:
> class Base { protected void foo(); }
> 
> developer 2:
> class Derived: Base { public void not_so_protected_foo() { foo() }
> 
> but that doesn't mean that "protected" in C++ shall be ditched!

In terms of reasoning about code that might break, protected is equivalent to public. The only advantage to protected over public is that it tells clients how to properly use it.

What does marking a method as “specialprivate” (my made up name for this new access level) tell clients about who can use it or how it can be used?

> 
> this is similar to what you said before about writing an extension and exposing the private functionality as public violating protection.
> 
> Mike
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171030/3a99008c/attachment.html>