> On Feb 21, 2017, at 8:00 AM, Brent Royal-Gordon <br...@architechies.com> > wrote: > >> On Feb 20, 2017, at 5:56 PM, Robert Widmann via swift-evolution >> <swift-evolution@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 > _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
