> On Nov 1, 2017, at 11:09 AM, Mike Kluev via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> On 1 November 2017 at 15:31, BJ Homer <bjho...@gmail.com
> <mailto:bjho...@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.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
