<div dir="ltr">On 30 October 2017 at 17:22, Adam Kemp <span dir="ltr">&lt;<a href="mailto:adam_kemp@apple.com" target="_blank">adam_kemp@apple.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><br><div><div>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.</div></div></div></blockquote></div><br></div><div class="gmail_extra">the new bucket would be &quot;class and all of its extensions be them in the same file or in different files&quot;.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">back to your example with the locked door and the keys on the doorstep, i can violate &quot;protected&quot; in C++:</div><div class="gmail_extra"><br></div><div class="gmail_extra">developer 1:</div><div class="gmail_extra">class Base { protected void foo(); }</div><div class="gmail_extra"><br></div><div class="gmail_extra">developer 2:</div><div class="gmail_extra">class Derived: Base { public void not_so_protected_foo() { foo() }<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">but that doesn&#39;t mean that &quot;protected&quot; in C++ shall be ditched!</div><div class="gmail_extra"><br></div><div class="gmail_extra">this is similar to what you said before about writing an extension and exposing the private functionality as public violating protection.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Mike</div><div class="gmail_extra"><br></div></div>