> What is your evaluation of the proposal?
Very strong -1. Drew has said it all. A few extra points: * If you split a class into a bunch of extensions, chances are it's a large class, and fileprivate keyword provides crucial *documentation* on which methods and fields are accessed from outside the scope. Even if someone blindly uses private until compiler complains, then switches to fileprivate without thinking, there's still value when reading the code. (This has been mentioned as one of the points against scoped private.) * Encapsulation is in the spirit of Swift's safety goals, we want to encourage it. * // MARK is perfectly fine for tightly-coupled class bodies, so if you find yourself using tons of fileprivate, consider switching to a single body with marks * I really like the point that we should uphold the original decision unless we find new compelling arguments that were not considered initially. > Is the problem being addressed significant enough to warrant a change > to Swift? No. I haven't personally seen any complains about this feature in my circles; everyone is happy about tighter access controls. > Does this proposal fit well with the feel and direction of Swift? It feels actively against the safety and readability goals of Swift. > If you have used other languages or libraries with a similar feature, > how do you feel that this proposal compares to those? This has been beaten to death in the original proposal. > How much effort did you put into your review? A glance, a quick > reading, or an in-depth study? Thorough reading of the first half of this discussion, and active participation in the original discussion (as well as writing and shipping lots of Swift code since Swift 0.x). A.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
