[swift-evolution] classprivate protection level?
adam_kemp at apple.com
Mon Oct 30 12:22:26 CDT 2017
> On Oct 30, 2017, at 10:10 AM, Mike Kluev <mike.kluev at gmail.com> wrote:
> On 30 October 2017 at 16:34, Adam Kemp <adam_kemp at apple.com <mailto:adam_kemp at apple.com>> wrote:
> I didn’t mean “no, you can’t do that”. You can if you want to. What I meant was “no, I’m not suggesting that you should do that”. I don’t think it’s necessary.
> as you said before the benefit of keeping private things private is minimizing the amount of code that can break once you change a variable. if it's "internal" - the whole module must be checked. if it is "internal" rather than "private”:
> it is done because otherwise i'd have to keep the (big) class in a single file
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution