[swift-evolution] Type-based ‘private’ access within a file

[David Hart]

> On 4 Apr 2017, at 17:26, Shawn Erickson via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Mon, Apr 3, 2017 at 8:38 PM Adam Knight via swift-evolution <swift-evolution at swift.org> wrote:
>>> On Apr 3, 2017, at 8:11 PM, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> My remaining hope is that Swift will acquire a submodule design which renders “fileprivate” essentially redundant. If we get an access level that means “visible in a group of tightly-related files” and it has a concise spelling, then I will use that just about exclusively.
>> 
>> You mean a namespace?  Ask some greybeard C++ developers how that one worked out.
>> 
>> Honestly, regardless of names, I see the following needs:
>> 
>> 1. Keep your mitts off this code, this is for me alone. You will break things if you change this.
>> 2. This one is for me and my relatives who know what we're doing with it.
>> 3. This is for my group as we work together on this problem.
>> 4. This is for anyone that wants us to solve this problem for them.
>> 5. This is for anyone that wants to try to solve this problem some other way.
>> 
>> (private, protected, internal, public, open — perhaps?)
>> 
>> What we call them matters little, as long as none of those names are fileprivate. 🙂  File-based access control is so very ‘70s (and this is coming from someone who has used C for a Very Long Time and loves it more than Swift, honestly). For *this* language, it’s the wrong tool.  We have those new-fangled hierarchical types and extensions all in those fancy little modules, so let’s use them as the people expect them to be used.
>> 
>> When submodules are A Thing, revisit them in terms of the “definitions" above and see where things fit.  If we — heaven forbid — think we need an additional “export” keyword then we’ll have that firefight
> 
> Yeah basically my main objection to this proposed change and my general dislike with current access controls is that they continue to depend on file level scoping to provide for a functionality like "protected" in C++ (not that I exactly want that either, at least not friend). This forces you to organize things in certain ways if you want to do anything more then internal module level access.

Even if you don't like it, Swift's access control's reliance on file scoping is here to stay. It's too late to change that.

> I don't like the proposal primarily because it conflates file scope and private scope which I think makes things more confusing and builds more on the "crutch" of a file construct for access control. I much rather keep things clear and explicit by requiring the use of fileprivate for those situations instead of muddling up private (at least for now).

It's true that it conflates lexical and file scope. That's it's one drawback.

> Instead I would want a protected like thing to be looked at that would replace the need for fileprivate and that should be looked at in conjunction with sub modules and likely properties, etc. ...let's spend out energy on breaking away from file based access control. (that would make playground better as well)

Whatever we want, the core team has made it clear that access levels won't be changing as substantially as that from now on. That's the entire reason 0159 was rejected: to not break source compatibility with users of private & fileprivate. So how can we expect any major change in the future?

That's why the current type-based proposal is the only viable alternative we have to resolve the grievances 0159 brought forward now. There's no "later".

> I feel most of the access controls levels in swift are well setup for progressive disclosure... internal by default it great, you can get to work without needing to know access controls. You can start to learn it by putting your code in modules and dealing with public (and sometimes open) which is great first way to understand the what and why of wanting to control access to things. You can then start to learn about inter-module encapsulation using private and then fileprivate.
> 
> -Shawn
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170404/ca8a1b8d/attachment.html>