> On 7 Apr 2017, at 9:10 am, Douglas Gregor via swift-evolution > <swift-evolution@swift.org> wrote: > > Hello Swift community, > > The review of SE-0169 "Improve Interaction Between private Declarations and > Extensions" begins now and runs through April 11, 2017. The proposal is > available here: > > https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md > Reviews are an important part of the Swift evolution process. All reviews > should be sent to the swift-evolution mailing list at > > https://lists.swift.org/mailman/listinfo/swift-evolution > or, if you would like to keep your feedback private, directly to the review > manager. When replying, please try to keep the proposal link at the top of > the message: > > Proposal link: > > https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md > Reply text > Other replies > What goes into a review? > > The goal of the review process is to improve the proposal under review > through constructive criticism and, eventually, determine the direction of > Swift. When writing your review, here are some questions you might want to > answer in your review: > > What is your evaluation of the proposal? It pains me to say this: -1. I think this is a bandaid solution.
Swift had a simple module based access control. Was it the right one? Debatable. But at least the story was consistent and it worked. Then Scoped access came along rather than trying to really flesh out the problem of access control, and for some stupid reason, we chose to make private scoped and introduce a terrible access modifier for what was "private" before. We don't have submodules yet. When they come, we need to flesh this stuff out, and deal with concepts like "protected" ect rather than ignoring them like we seem to be doing. I think reverting the behaviour (in the previous proposal) was right short term, but not long term, and created unnecessary churn. But the fight for Swift source stability needs to take a back seat to getting this right in the Swift 5 timeline and we need to accept that some level of pain will come because we need to rework this stuff to get it right for the future. > Is the problem being addressed significant enough to warrant a change to > Swift? Yes. We need to sort out access control. The current solution seems ill equipped for the future. > Does this proposal fit well with the feel and direction of Swift? No. It is a bandaid solution which confuses the point of 'private'. Is it scoped, or a weird mid-way between a scoped and fileprivate? > If you have used other languages or libraries with a similar feature, how do > you feel that this proposal compares to those? Some with access control, and our system seems broken. > How much effort did you put into your review? A glance, a quick reading, or > an in-depth study? Quick reading. > More information about the Swift evolution process is available at > > https://github.com/apple/swift-evolution/blob/master/process.md > Thank you, > > -Doug > > Review Manager > > _______________________________________________ > 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
