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

Jaden Geller jaden.geller at gmail.com
Tue Feb 21 08:04:46 CST 2017


> On Feb 21, 2017, at 5:00 AM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> 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.

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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



More information about the swift-evolution mailing list