[Pitch N+1] Submodules and Access Levels


there are a lot of proposals floating around at the moment and I want to present my point of view.
I’ve read most of the discussion, but not everything and instead of replying to all the individual mail,
I’ll just add pitch N+1 into the mix. At the current level of discussion I hope that’s the best thing to do
in order to arrive at a consistent set of features.

Actually, I’m quite happy with the current set of access levels in Swift.
While I never was no fan of SE-0025, I can live with it.
Reverting it makes the language a little bit simpler, so in this mail I’ll just use `private`.
If you want to keep `fileprivate`, then just read every `private` as `fileprivate`.
I do like the new `open` so I’ll use it here.
If the community comes up with something different here, then also just replace it here.
I’ll try to concentrate on the interaction of modules and access levels,
which is more or less orthogonal to the concrete syntax.

What do we want to achieve?
* Add more structure to packages and modules;
* Allow some set of symbols which can be imported by a client but which are not imported by default;
* Provide symbols to other modules/submodules of the same package without having to export them to the whole world.

My biggest point here is, that each entity should explicitly specify what get’s exported to clients.
I.e. symbols should not already be exported, just because they happen to be specified `public` in some module or submodule.

Something like this has already been proposed:

I very much prefer Brent’s alternative

So this serves the same goal as `__init__.py` files in Python, but we wouldn’t require any magic name.
We could have a convention of using `init.swift` or `module.swift`/`package.swift`.
But at the end it would be up to the package author (because maybe she wants to use separate files to specify the exports).



Ups accidentally sent an old draft, please disregard...