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

[Brent Royal-Gordon]

> On Feb 21, 2017, at 6:09 PM, Robert Widmann <devteam.codafi at gmail.com> wrote:
> 
>> 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 think you're missing my point.

What you appear to be saying is: "If two things need privileged access to each other, they should be in the same module; if they should hide implementation details from each other, they should be in different modules." But it's perfectly possible for two things to *both* need privileged access to some APIs *and* hide implementation details from one another.

Basically, my objection is, this proposal requires that parent modules only communicate with submodules through fully `public` APIs which are also available outside the module. If you want to encapsulate certain implementation details by putting them in a submodule, you must paradoxically expose other details—the APIs through which the parent module is supposed to interact with the submodule—to the whole world. That restriction conflicts with Swift's important goal of ensuring that libraries only expose API surface they're committed to supporting indefinitely.

Basically, I think that either we need a new access level meaning "visible to the top-level module and all of its submodules, but not to other modules", or we need a way to specify that a submodule is internal-only and shouldn't be importable by outside code. My submodule sketch the other day took the second approach, but I think one or the other is necessary if we want submodules to serve both as public units of API surface and private encapsulators of implementation detail.

-- 
Brent Royal-Gordon
Architechies