> On Jul 18, 2016, at 6:01 PM, Brent Royal-Gordon <[email protected]>
> wrote:
>
>> On Jul 18, 2016, at 5:33 PM, Robert Widmann <[email protected]> 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
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
