> On Mar 20, 2017, at 4:54 PM, Douglas Gregor <[email protected]> wrote:
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md > > <https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md> > What is your evaluation of the proposal? +1. > Is the problem being addressed significant enough to warrant a change to > Swift? Yes. Adding a fourth level of access control has greatly increased the complexity of the language (search the mailing lists for various discussions about corner case behavior caused by the existence of the new scope-level 'private') for (what I believe to be) very little benefit. To be clear, I am not opposed to additional access control levels in principle. Swift might require more powerful access control in the future. There seems to be a consensus that Swift should gain some sort of code organization facility, whether in the form of namespaces, submodules, or something similar. Any additions to the access control system should take into account whatever solution to this code organization problem Swift eventually decides to go with, and should address a pain point that a wide range of Swift developers have actually experienced (since any such addition is going to add some level of unavoidable complexity which every developer will need to deal with). In my opinion, the Swift 3 behavior fails both of these tests and should be deprecated. > Does this proposal fit well with the feel and direction of Swift? Absolutely. It is extremely easy to add features to a language. While we try our best, we cannot predict all the consequences of adding a feature. Nor do we always make a good judgement as to whether the complexity added by such features is justified by the additional functionality they provide. Removing features is more difficult: the window to do so without imposing undue burden on developers is small, almost every feature is going to be used by at least a handful of developers, and removing functionality is intrinsically less appealing than adding it. Yet in decision after decision the core team has reiterated their desire to not add features simply because they might be useful, but rather to rigorously ensure that new features "earn their keep" in terms of additional power versus complexity. Past experience has shown that this is often the right decision, and that removing features that fail this test will not seriously damage the language or community. Admitting that we erred and accepting this proposal does *not* affect our ability to thoughtfully improve the access control system in the future. Rejecting it ensures that all proposals to improve access control in the future, including proposals that could supersede the functionality of Swift 3's 'private', are necessarily going to be more difficult to understand and more difficult to implement than they would be otherwise. > If you have used other languages or libraries with a similar feature, how do > you feel that this proposal compares to those? While not a perfect system, the concept of private and public header files in Objective-C (and true 'private' declarations at the top of a source file) has, in my experience, been adequate for the needs of a variety of different types of software, including projects being worked on by small and large teams, as well as both libraries and applications. Swift 2's three-level access control system was a refinement of this previous convention and, in my opinion, struck the proper balance between granularity, safety, and programmer ergonomics. > How much effort did you put into your review? A glance, a quick reading, or > an in-depth study? I read the proposal when it was first presented and have followed many, many threads about both the proposal and about 'private' and 'fileprivate' on the lists. > More information about the Swift evolution process is available at > > https://github.com/apple/swift-evolution/blob/master/process.md > <https://github.com/apple/swift-evolution/blob/master/process.md> > Thank you, > > -Doug > > Review Manager > > _______________________________________________ > swift-evolution-announce mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution-announce
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
