- What is your evaluation of the proposal? + 1
- Is the problem being addressed significant enough to warrant a change to Swift? Yes - Does this proposal fit well with the feel and direction of Swift? I'm not completely sure. - If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those? Mixed. I won't get into all of the things I wish it did or did not have. - How much effort did you put into your review? A glance, a quick reading, or an in-depth study? I've followed the discussions and read the proposals. Overall, I don't think that this is necessarily ideal but I do believe that it would be a net positive for the reasons stated. `private` would become more common and `fileprivate` less. On Mon, Apr 17, 2017 at 4:23 PM, Riley Testut 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. > > > 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 > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution