> On Mar 25, 2017, at 6:46 AM, Jonathan Hull <[email protected]> wrote:
>
>> On Mar 25, 2017, at 6:39 AM, Brent Royal-Gordon <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>> On Mar 25, 2017, at 12:32 AM, Jonathan Hull via swift-evolution
>>> <[email protected] <mailto:[email protected]>> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
