> 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.
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. Fileprivate is different. It was intended to be used rarely, as another form of progressive disclosure, and when it was 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 loses 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. 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. FWIW, I really don’t view this proposal as just a stop-gap, I think accepting this proposal will genuinely be the best 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 :^) > On Apr 17, 2017, at 1:08 PM, David Hart via swift-evolution > <swift-evolution@swift.org> wrote: > > 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.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
