[swift-evolution] [Proposal] Qualified Imports and Modules

[Robert Widmann]

> On Jul 18, 2016, at 6:01 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
> 
>> On Jul 18, 2016, at 5:33 PM, Robert Widmann <rwidmann at apple.com> wrote:
>> 
>>> 2. Filenames are freeform; any file can declare itself to belong to any submodule. Obviously, best practice would be to give your files sensible names that have some kind of link to the submodule name, but this would be a linter concern.
>> 
>> How does this interact with duplicate declarations?
> 
> Then they are part of the same submodule.
> 
> For instance, take a look at the GroupInfo.json file cited in the proposal: <https://github.com/apple/swift/blob/master/stdlib/public/core/GroupInfo.json> The Swift.String submodule consists of 18 separate files. Each of these would have `submodule String` at the top, and they would all share a single `internal` scope separate from the internal scope of the Swift module as a whole.

It seems like that kind of scoping can just fall under “whatever my submodules are, I’d like to be able to see into them”.  If you think of a module and its submodules as a tree, an internal module scope is a branch and its children and a set of private declarations are the leaves.

>>> 3. Each submodule has its own `internal` scope. Submodules can import the `internal` scopes of specific peer modules with an annotation like `@testable` (but probably renamed). 
>> 
>> "Peer modules” is something we can lock down without having to introduce even more scopes and fits well within this proposal.  A restriction like “a module may only import private members from submodules 1-level deeper than themselves” for example.
> 
> I assume you mean `internal` members; exposing `private` members outside the scope they're declared in, or `fileprivate` members outside the file they're declared in, is problematic.
> 
> What I'm suggesting is that, for instance, StringCharacterView.swift can write:
> 
> 	submodule String
> 	@testable /* or whatever */ import Swift.Collection
> 	
> 	extension String {
> 		struct CharacterView: Collection {
> 			// And we can use internal-only Collection calls here
> 		}
> 	}
> 
> We could certainly make rules restricting you to only importing (say) immediate siblings or immediate children, but I think that might end up being overly bureaucratic. The combination of a module and its submodules form a single whole, released together and controlled by the same organization. I see little need for elaborate tying of hands.
> 

Which is why the proposal originally allowed you to say something like internal import Swift.Collection rather than express a group of “friends” that can import from each other.  If you want to ask for the contents of a non-exported module from another within the same project, at least you have to be explicit about what kind of access you want.  I think we have similar goals for private access here, it’s just a matter of expression.

>>> Tests are treated as a submodule of the main module, so they can participate in this mechanism just like everyone else.
>> 
>> Or we could keep the existing @testable import syntax.  It will still work exactly the way it always has under this proposal.
> 
> I'm trying to merge two similar mechanisms into one. We need some way to have SPIs between submodules within a module; it seems sensible to rework `@testable`, which creates SPIs between a module and its tests, into this mechanism.
> 
>>> 4. `import` only ever imports the `public` (or `internal`, with the `@testable` equivalent) symbols in the specified submodule. It re-exposes them with the access modifier on the `import` statement, or `private` by default. It does not re-expose `internal` symbols as `public`. `using`, `hiding`, and `renaming` apply to all comers, not just the current file.
>> 
>> We do not allow you to re-export any API that is not public.  The wording around the section you keep bringing up is vague and needs to be fixed.
> 
> Yes—I'm merely restating that to emphasize that it's part of my approach.
> 
> -- 
> Brent Royal-Gordon
> Architechies
>