> On Feb 21, 2017, at 5:00 AM, Brent Royal-Gordon via swift-evolution > <[email protected]> wrote: > >> On Feb 20, 2017, at 5:56 PM, Robert Widmann via swift-evolution >> <[email protected]> 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.
It might be reasonable to allow access control modifiers to be used with modules. — `private` module declarations can only be imported in the scope in which they were defined — `fileprivate` module declarations can only be imported in the file in which they were defined — `internal` module declarations can be imported anywhere in the outermost (?) module — `public` module declaration are exported to consumers of the outermost module Definitely more thought needs to go into this, but it might address this desire. > > (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.) I think using `submodule` as a keyword is both reasonable and a good idea. It does become problematic if/when we eventually want to allow entire files to be part of a submodule though… > > -- > Brent Royal-Gordon > Architechies > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
