Proposal link: > https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
> On Apr 6, 2017, at 4:10 PM, Douglas Gregor <[email protected]> wrote: > > What is your evaluation of the proposal? This proposal is actively harmful. It will push people into using patterns we discourage, like converting between types by using properties or methods on the source type instead of initializers on the destination type. It will cause people to distort their designs, moving implementations into different types solely to gain access to `private` members. I don't like scoped `private` either, but at least it has its uses: It's an effective tool when a member has fragile, easily-broken invariants and you want to ensure only carefully-audited code can use it. Type-and-file `private` is not fit for this purpose: Even if you segregate the fragile parts into a separate type, you can just extend that separate type anywhere else in the file and start messing with it. Frankly, I don't think type-and-file `private` is fit for *any* purpose. At the same time, type-and-file `private` does not simplify our access modifier scheme, forces people to re-learn what `private` does *again*, and silently removes the protection that people currently rely on scoped `private` to provide without so much as a whimper from the compiler. Keeping scoped `private` offers the following virtues: * Your code doesn't change meaning or protection * You don't have to re-learn what `private` means * You can tightly protect fragile parts of a type, completely limiting visibility to one small region of the code Making `private` and `fileprivate` aliases for one another offers the following virtues: * You will never have to use the ugly `fileprivate` keyword * Teaching and explaining access control is simpler * You never have to put any piece of code in any particular type Giving `private` type-and-file semantics offers the following virtues: * You (hopefully) will have to use the ugly `fileprivate` keyword a little less often That's it. That's *absurdly* far from being worth it. This proposal is the worst of both worlds: weaker encapsulation without simplification, bad incentives without good guarantees, complexity without benefit, change without improvement. It should be rejected. > Is the problem being addressed significant enough to warrant a change to > Swift? Access control is a mess, but this proposal does not address the things that make it a mess. > Does this proposal fit well with the feel and direction of Swift? No. This is a direction we have specifically and repeatedly chosen not to go in for many very good reasons. Those reasons still hold. > If you have used other languages or libraries with a similar feature, how do > you feel that this proposal compares to those? Swift 2's design was simple and elegant. Swift 3's was irritating but sometimes useful. This proposal keeps the irritation while discarding the usefulness. > How much effort did you put into your review? A glance, a quick reading, or > an in-depth study? Like all of us, I have spent *way* too much time arguing about access control in the last few months. -- Brent Royal-Gordon Architechies
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
