<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class="">I think its important to point out that its more than aesthetics: because the simple file and extensions scenario are so common, it forces us to use both private and fileprivate fairly regularly, which increases the total number of access control to work with on a daily basis. And I think that’s the important point. That’s why open is a success IMHO: because it only needs to be used rarely, it provided the required functionality without increasing the number of access modifiers that needed to be used regularly.</blockquote><br class=""></div><div class="">I agree 100%. I’ve never been a fan of open, and still disagree with the rationale for why it was added. However, because it does follow Swift’s progressive disclosure emphasis, and because it does accomplish what it was designed to do, I’ve made peace with it.</div><div class=""><br class=""></div><div class="">Fileprivate is different. It was intended to be used rarely, as another form of progressive disclosure, and when it <i class="">was</i> used, it had meaning. However, as has been discussed many times, this is not the case. Fileprivate, for a multitude of reasons, is used far more frequently than anticipated (fileprivate is certainly used way more than private in my own projects), and as a result <i class="">loses </i>its meaning. When looking at a fileprivate declaration, there is no way to know whether it is intended to be exposed to separate types, or simply to extensions of the same type.</div><div class=""><br class=""></div><div class="">Again, I personally think access control was far simpler in Swift 2. However, because the idea of scoped access clearly has value to many developers, I am okay with adding that functionality to the language. By allowing extensions to access private variables, fileprivate has actual meaning again (which was the original intention) and is also something that many developers may never need to use.</div><div class=""><br class=""></div><div class="">FWIW, I really don’t view this proposal as just a stop-gap, I think accepting this proposal will genuinely be the <i class="">best</i> option for Swift in general. I personally don’t like the idea of renaming private to scoped, since I think private and fileprivate are better terms in general. I just want private member access in my extensions for God’s sake :^)</div><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 17, 2017, at 1:08 PM, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">I think its important to point out that its more than aesthetics: because the simple file and extensions scenario are so common, it forces us to use both private and fileprivate fairly regularly, which increases the total number of access control to work with on a daily basis. And I think that’s the important point. That’s why open is a success IMHO: because it only needs to be used rarely, it provided the required functionality without increasing the number of access modifiers that needed to be used regularly.</span></div></blockquote></div><br class=""></body></html>