> On Oct 30, 2017, at 10:10 AM, Mike Kluev <mike.kl...@gmail.com> wrote: > > On 30 October 2017 at 16:34, Adam Kemp <adam_k...@apple.com > <mailto:adam_k...@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.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
