What is your evaluation of the proposal? –1 However I do support the reverting meaning of the keyword, but I’m against obliterating the powerful scoped access modifier. That said, I’m against the breaking change for Swift–4, which only fixes a tiny peace of the access control system.
Is the problem being addressed significant enough to warrant a change to Swift? It is not, because a personal preference of a naming convention should not be enough for a breaking change that obliterates flexibility of the language. We also could make everything public (and open), to completely remove the complexity from the language and blame the client for misunderstanding the intentional design of our libraries. However this would be simply ridiculous and complete nonsense if we’d go that route. Does this proposal fit well with the feel and direction of Swift? Yes and no. I think that most of us do agree that fileprivate was a bad naming choice, but the need of flexible access modifiers which contains a stricter version of the private keyword is undeniable. Even though not all of us do need it and may see that modifier as more complexity for the language, others do need that much flexibility. If we’re going ever to fix access control in Swift again then it should be deferred to post Swift–4 where we tackle it as a whole, but not simply one access modifier after an other. We already made a mistake with fileprivate, but so we did with open and public with a separate proposal. Matthew Johnson had a far superior proposal on how to fix this mess, which is apparently out of scope of Swift–4. How much effort did you put into your review? A glance, a quick reading, or an in-depth study? Quick reading. -- Adrian Zubarev Sent with Airmail
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
