> On Oct 30, 2017, at 10:57 AM, Mike Kluev <[email protected]> wrote:
>
> On 30 October 2017 at 17:22, Adam Kemp <[email protected]
> <mailto:[email protected]>> 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
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
