[swift-evolution] [Proposal][Discussion] Modular Swift

[Robert Widmann]

> On Feb 21, 2017, at 8:00 AM, Brent Royal-Gordon <brent at architechies.com> wrote:
> 
>> On Feb 20, 2017, at 5:56 PM, Robert Widmann via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> The semantics of some existing access control modifiers shall also be extended to support module declarations:
>> 
>> 	• open and public declarations are exported by a module for consumption by clients of the module.
>> 	• internal declarations scope over the entire module and any derived submodules.
> 
> If I'm reading this correctly, you're proposing that the `internal` APIs in a submodule should *not* be accessible to enclosing modules. I also don't see any indication that you can control who is allowed to import a particular submodule.
> 
> That means that, if you use a submodule to encapsulate internal state, the APIs that are available to the parent module are *also* available to any rando who feels like importing your submodule. I don't think that's going to be a tenable design.

If the state is truly internal, and you are using internal access control, this is impossible.  The internal state cannot cross the module boundary unless it is marked public.  If a “random” feels like importing my submodule, they will not have access to any symbols.

> 
> (I have a couple other objections—I think the keyword ought to be `submodule` if you don't need a top-level `module` declaration, I think there's a lot to be said for a single declaration covering the entire file, and I'm pretty iffy on this entire approach anyway—but this seems like the most serious problem of the bunch.)
> 
> -- 
> Brent Royal-Gordon
> Architechies
>