Hi,
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:
https://github.com/anandabits/swift-evolution/blob/scope-based-submodules/proposals/NNNN-scope-based-submodules.md
<https://github.com/anandabits/swift-evolution/blob/scope-based-submodules/proposals/NNNN-scope-based-submodules.md>
I very much prefer Brent’s alternative
TBD
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).
—
Martin
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
