[swift-evolution] continuations - "extensions on steroids" idea

[Noah Desch]

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 at 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.
>>