[swift-evolution] A Comprehensive Rethink of Access Levels in Swift

Jonathan Hull jhull at gbis.com
Mon Feb 27 19:27:13 CST 2017

>>>> What I like about ‘hidden’ vs export of nested submodules is that you can freely intermix those declarations in your code (like you can with private now).
>>> Yeah, this is an advantage.  It’s not a bad idea, but it’s not a replacement for submodules either.  They are complementary.  
>> Agreed.
>> What I would really like to see is Nevin’s proposal with a simplified version of yours providing the submodules, and something like ‘hidden’ replacing the idea of ‘export’.
> Are you saying you want to see all submodules exposed externally automatically?  Or are you only talking about non-top-level export?

In Nevin’s system (to the best of my understanding), Submodules don’t really have much to do with visibility except to define a boundary.  Things marked ‘private' are visible within a submodule, but not outside of it.  Things marked ‘internal’ are visible within the entire module, but not outside of it.  Things marked ‘public’ are visible everywhere.  

Submodules don’t have visibility of their own in this system (which is part of what I like about it). Once you start having to worry about the visibility of the submodule itself, it really complicates the model, and you find yourself thinking on a much more abstract level instead of writing code. 

>> In more detail, I really like just having ‘private’, ‘internal’, and ‘public’ where private means private to the submodule.  It is very simple and understandable.  I think having a single level of submodule using your ‘submodule’ syntax is the simplest way to provide those.  
> I think there is going to be *a lot* of resistance to the idea of removing file-level private.  Most people want to keep that, but just revert than name to `private` like we had in Swift 2. 

As I said above, Nevin’s system redefines ‘private’ to always mean private to the enclosing submodule. If you have not defined an explicit submodule for your file, then the file itself is implicitly it’s own submodule (aka. the same behavior as fileprivate)

>> I think I would be ok with nested submodules as well, again using your syntax, as long as we have ‘private’ mean private within the current submodule (and children).  If we find we really do need parametrized private (or equivalent) to provide visibility to a specific parent scope, that is something that can be an additive (non-breaking) change later.  I think we will be able do pretty much everything we need to without it though.
> I could be wrong, but I’d be willing to bet that in a submodule world you would have a very vocal and large number of people complaining if we suggest not including any of: module-wide visibility, submodule-wide visibility and file-wide visibility.
These are all provided for under the proposal (with file-wide visibility for anonymous submodules).

If we wanted to allow nested submodules though, ‘private’ would still mean private to your containing submodule.  Other things in the submodule could see it, as could any child submodules, but anything outside the submodule could not.  What I am saying is that I don’t think we will need 'private(submoduleName)’, but we can always add it in a non-breaking way if I am wrong about that.

>  There are certainly people who think that one or another of these is not worth supporting but I don’t see anything near a consensus around avoiding any one of these.  Each will have a very vocal group of proponents that I believe (again I could be wrong) would be a majority with respect to that particular scope.  
> I can understand why somebody might prefer a style that avoids relying one of these scopes (people have their idiosyncrasies after all).  What I have a hard time understanding is why somebody would propose that *nobody* be able to scope a symbol to one of these very physical and prominent scopes.

The only scope which would be lost is private to the type (what we currently call ‘private’ in Swift 3).  Basically it works exactly like Swift 2 did, but you have the added ability to extend the domain of private by using submodules…

I like your notation for defining submodules, and would like to see that added, as well as my idea of ‘hidden’ to cover the needs I talked about before.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170227/e53d1d27/attachment.html>

More information about the swift-evolution mailing list