IMO the ledger isn’t just about access control, it’s also about having a convenient (and guaranteed correct, due compiler enforcement) place to see where the rest of your class is defined.
I’m +1 on the ledger and partial classes in general. I think extensions serving the dual purpose of extending other module’s classes, as well as an organizational tool for in-module classes has resulted in some bad choices and makes future development harder. Having a new construct for in-module class organization neatly solves the problem. (I still want C++’s protected scope too though, in case there was any doubt). > On Nov 2, 2017, at 9:37 PM, Adam Kemp via swift-evolution > <swift-evolution@swift.org> wrote: > > I will echo what several other people said in the previous discussion: you > have to trust your fellow developers. By declaring a class as “partial” you > are allowing that class to be extended elsewhere. Typically that would mean > in an adjacent file named ClassName.Foo.swift (next to ClassName.swift). It > should be highly discouraged to extend the class using partial from anywhere > else, and listing tools can enforce that if needed. But at the end of the day > if you can’t trust your fellow developers not to do that then you can’t trust > them not to add a new name to the ledger either. > > And in case someone was wondering why I’m ok with this and not the > “classprivate" idea, the key difference here is that this is opt-in. I’m > still not ok with a random extension being able to access private fields of > any class by default. Partial classes should be an exception for specific use > cases, not a default behavior. >> _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
