<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi,<div class=""><br class=""></div><div class="">there are a lot of proposals floating around at the moment and I want to present my point of view.</div><div class="">I’ve read most of the discussion, but not everything and instead of replying to all the individual mail,</div><div class="">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</div><div class="">in order to arrive at a consistent set of features.</div><div class=""><br class=""></div><div class="">Actually, I’m quite happy with the current set of access levels in Swift.</div><div class="">While I never was no fan of SE-0025, I can live with it.</div><div class="">Reverting it makes the language a little bit simpler, so in this mail I’ll just use `private`.</div><div class="">If you want to keep `fileprivate`, then just read every `private` as `fileprivate`.</div><div class="">I do like the new `open` so I’ll use it here.</div><div class="">If the community comes up with something different here, then also just replace it here.</div><div class="">I’ll try to concentrate on the interaction of modules and access levels,</div><div class="">which is more or less orthogonal to the concrete syntax.</div><div class=""><br class=""></div><div class="">What do we want to achieve?</div><div class=""> * Add more structure to packages and modules;</div><div class=""> * Allow some set of symbols which can be imported by a client but which are not imported by default;</div><div class=""> * Provide symbols to other modules/submodules of the same package without having to export them to the whole world.</div><div class=""><br class=""></div><div class="">My biggest point here is, that each entity should explicitly specify what get’s exported to clients.</div><div class="">I.e. symbols should not already be exported, just because they happen to be specified `public` in some module or submodule.</div><div class=""><br class=""></div><div class="">Something like this has already been proposed:</div><div class=""><a href="https://github.com/anandabits/swift-evolution/blob/scope-based-submodules/proposals/NNNN-scope-based-submodules.md" class="">https://github.com/anandabits/swift-evolution/blob/scope-based-submodules/proposals/NNNN-scope-based-submodules.md</a></div><div class="">I very much prefer Brent’s alternative </div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">TBD</div><div class="">So this serves the same goal as `__init__.py` files in Python, but we wouldn’t require any magic name.</div><div class="">We could have a convention of using `init.swift` or `module.swift`/`package.swift`.</div><div class="">But at the end it would be up to the package author (because maybe she wants to use separate files to specify the exports).</div><div class=""><br class=""></div><div class="">— </div><div class="">Martin</div></body></html>