> On Feb 21, 2017, at 9:38 PM, Brent Royal-Gordon <br...@architechies.com> > wrote: > >> On Feb 21, 2017, at 6:09 PM, Robert Widmann <devteam.cod...@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.
That is not what this proposal requires. A public API is ripe for re(export), but if the parent wishes to communicate with its children without exporting across the module boundary, see the definition of `internal`. > > 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 > _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
