On 30 October 2017 at 17:22, Adam Kemp <[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".
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!
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
