[swift-evolution] access control proposal

[Matthew Johnson]

> 
> I think the simplest counter-example is your own example for extensions. Each extensions will need access to different internals of the the type it’s applied to. So when it comes time to add that extension, you’ll be forced to promote the access control from “local” to “private”.

I was referring specifically to extensions that *do not* require private access to the type, but rather work exclusively with its internal or public members.  Extensions such as this are not uncommon and may have implementation details of their own which do not need to be visible outside the extension.

> 
> Another straight-forward one is a subclass. Since “local” would be “scope” based, a subclass would also knot have access to those members defined as local in the super class, so they’d have to be promoted to private and thus available to all code within the file.

We are not discussing protected access here.  I don’t like it and would not support adding it to Swift.

Matthew