<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 29, 2016, at 10:18 AM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">A good handful of people already enumerated several cases where file-based scoping is useful, and I very much agree. Leaking helper operations across an entire module just because they can't be lexically scoped, or don't make sense to, doesn't seem like a good answer to me.</div></div></blockquote></div><br class=""><div class="">I know, I'm one of them.</div><div class=""><br class=""></div><div class="">However, this thread is fairly disconcerting about how granular many of the suggestions are heading towards. We can try to solve for all of the cases or we can provide mechanism that works well for the majority of cases. I'm actually in the camp of keeping the levels as they are. There is always going to be some level of leakage unless you provide a mechanism to provide very explicit access control modifiers.</div><div class=""><br class=""></div><div class="">The question at the heart of this proposal is how "correct" is Swift really going to be in defining access control modifiers?</div><div class=""><br class=""></div><div class="">One can argue that file-based access control is required, for many use cases, because it's not possible to limit usage to be "more correct". If I want to expose the private details of my type to an extension, how do I do that? Today, file-based, but tomorrow, is there a `protected` for this? What about only to all extensions within the module? Is that `protected internal`? Is there a way to limit the extensions that can have access to the privates, because there are real scenarios for that as well?</div><div class=""><br class=""></div><div class="">Then we need to go down the rabbit-hole for type-based access control modifiers as well, though maybe that's already alluded to with the extensions example, so we get `protected` and `protected internal` there as well.</div><div class=""><br class=""></div><div class="">So this gives us public, internal, private, file-based, protected (protocol/extension based), protected (inheritance based), protected internal (protocol/extension based), and protected internal (inheritance based). </div><div class=""><br class=""></div><div class="">And let's not forget the desire to share privates with others that are not in our access control scope, so we're back to needing something like `friend` to essentially merge other types into the same access control scope.</div><div class=""><br class=""></div><div class="">I really feel like I'm watching the evolution of C++ access modifiers in Swift. If that's the route the language and community wants to go, then ok. However, if Swift is really going to re-look at access levels, just looking at scoped access levels does not seem sufficient; it solves one, very narrow case, while ignoring many of the other cases. </div><div class=""><br class=""></div><div class="">-David</div></body></html>