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

[Brent Royal-Gordon]

> 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.

>> 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.

>> 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