> What is your evaluation of the proposal? + 1.
Don’t like to admit it but i favored the fileprivate modifier when it was introduced. Alas more experince with Swift has meant that I now very often catch myself changing private to fileprivate if for nothing else then to allow protocol conformance through extensions in the same file. Even though this may not be a good enough reason to make me go with supporting the proposal, the fact that access modifiers are fundamental to most modern PLs and fileprivate vs private as is is now adds too little while on the other hand adds another access modifier which IMHO should be simple and allow encapsluation (as some have said, internal and public are actually enough to achieve this) means for me this is something worth reverting. > 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? Yes. > If you have used other languages or libraries with a similar feature, how do > you feel that this proposal compares to those? Most other languages encapsulate based on type and inheritance, so this strays a bit by making private extend beyond the class definition itself. However, no other language I’ve used make use of extensions the way Swift does so it makes sense in a Swift environment. > How much effort did you put into your review? A glance, a quick reading, or > an in-depth study? Followed both the original conversation added fileprivate as well as the other conversations which led to this proposal. - Davor _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
