[swift-evolution] continuations - "extensions on steroids" idea
adam_kemp at apple.com
Wed Nov 1 13:32:44 CDT 2017
> On Nov 1, 2017, at 11:09 AM, Mike Kluev via swift-evolution <swift-evolution at swift.org> wrote:
> On 1 November 2017 at 15:31, BJ Homer <bjhomer at gmail.com <mailto:bjhomer at gmail.com>> wrote:
> Again, though, “anyone” here only means “anyone working in the same module”. Which is a very restricted set of “anyone”: it only includes people who already have full access, and could just modify the original struct anyway.
> by this logic we can conclude that "private" in C++ is absolutely useless, as anyone (like "anyone in the world with the header") can change the header from: "private: void foo();" to "public: void foo();" even without the need of having the corresponding source file with "void foo()". right?
Swift doesn’t have headers so this doesn’t really make sense here. The idea of a module is to be able to provide someone an immutable binary with a public interface. Someone consuming your code via a module won’t be able to modify the contents of that module and shouldn’t be able to access private methods of classes in that module or add new private fields or methods to classes in that module. I think we all agree on that. A module that your code uses is immutable to you.
But people who are building that module and already editing code within that module can and should be able to modify a class in that module any way they want. That should be obvious, right? That person can choose to directly edit the class in its main definition file, but (with partial classes as I’ve described) they could also choose to mark that class as partial and then add to it from a different swift file from within the same module. As a maintainer of that module there is absolutely nothing wrong with this. That’s why it’s important that this only be possible within that module.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution