[swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Brent Royal-Gordon]

> On Mar 25, 2017, at 6:46 AM, Jonathan Hull <jhull at gbis.com> wrote:
> 
>> On Mar 25, 2017, at 6:39 AM, Brent Royal-Gordon <brent at architechies.com <mailto:brent at architechies.com>> wrote:
>> 
>>> On Mar 25, 2017, at 12:32 AM, Jonathan Hull via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> 	• Remove ‘private’ keyword
>>> 	• Rename ‘fileprivate’ to ‘local’ with the understanding it now means local to the containing submodule
>>> 	• If no submodule is declared, the file is its own anonymous submodule
>> 
>> 
>> This is kind of not the place for a full submodule discussion, but: I don't think a submodule system which doesn't have a unit of encapsulation smaller than the entire submodule is going to work.

> 
> I am confused. Half of my email was about how to encapsulate smaller than the entire submodule using ‘module { }'

Yes, but then within a nested module, you can't make something visible only to the surrounding module; you can only make it too visible (by exposing it to `internal`) or not visible enough (by keeping it `private`). You can't even create a symbol in the outer scope and access the inner scope's symbol there, because it won't be able to access it.

This is the problem with all access levels based on arbitrary, nestable scopes: in any given place you can't address many of the scopes, so if need a visibility level other than the exact current scope, you have to make it much more widely visible than you'd prefer.

-- 
Brent Royal-Gordon
Architechies

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170325/6d828cbb/attachment.html>