<div dir="ltr"><div class="gmail_extra">As I see it, this new proposal misses the mark in both directions. It does not replace file-level visibility, because extensions of external types wouldn’t be able to work with private declarations in the same file. And it throws out a major use-case of scope-based access, which is to ensure that invariants are only touched in specific places.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The vast majority of the time, if I am working in a file I want to be able to access everything in that file. I think this is a phenomenal mental model to have. It is extremely simple, it covers the most common use cases perfectly, and it should be the soft default.</div><div class="gmail_extra"><br></div><div class="gmail_extra">To the extent that we want to support protecting things within a file, it is most beneficial to mark those declarations with a lengthy, unmistakeable blazon. That way when you are reading code and come across something like “fragilelocallyscoped var doNotBreakThisInvariant” you know that you must be extra cautious about modifying it. In particular, such invariant-sensitive items should not use the same keyword as other members, because if they did there would be no warning sign for them.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Let me be abundantly clear: when someone is working in a file, they can always change the access level of members if necessary. In order to protect invariants, scoped visibility must very clearly inform readers that *this item should not be touched* except via dedicated channels, and that its visibility *should not be changed* as well. To convey that, those declarations need to be distinct and unmistakable.</div><div class="gmail_extra"><br></div><div class="gmail_extra">If you are reading through a file with many “private” declarations and one or two “dangerproceedwithcaution” declarations, you are much more likely to think twice before widening an access level in a potentially invariant-breaking way than if they were all just “private”.</div><div class="gmail_extra"><br></div><div class="gmail_extra">So, if we are going to keep scope-based visibility at all, it should *definitely not* be spelled “private”. A longer, more-explicit keyword that stands out prominently would be best, though nearly anything including “scoped” would suffice as long as it is different from “private”.</div><div class="gmail_extra"><br></div><div class="gmail_extra">We *must not* spell the invariant-protecting, danger-warning access level “private”.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Leaving it as it is now would be *actively harmful*. Swift 4 is our last realistic chance to get this right. We made a mistake in Swift 3. For our own sake, and for the sake of the Swift language and its evolution process, please let us fix this.</div><div class="gmail_extra"><br></div><div class="gmail_extra">We can simultaneously solve the problem, retain scoped visibility, and restore the file-level meaning of “private”, simply by changing the spelling of two keywords. The core team’s reason for disfavoring that approach, namely “churn”, is easily overcome, as they themselves noted, by a fully automated migrator.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Nevin</div></div>