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

[David Hart]

> On 4 Apr 2017, at 19:21, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution at swift.org> wrote:
> 
> As I see it, this new proposal misses the mark in both directions. It does not replace file-level visibility, because extensions of external types wouldn’t be able to work with private declarations in the same file.

It’s intention is not to replace file-level visibility but to increase the usefulness of private’s lexical scope. In that regard, I’m happy that you think it does not replace file-level visibility: it leaves a use-case for fileprivate.

> And it throws out a major use-case of scope-based access, which is to ensure that invariants are only touched in specific places.

Is still retains most use-cases that private procured. The only capability that is not expressible in this model is to hide private members in a declaration or extension from other declarations/extensions of the same type. But it still allows hiding the member from other types in the same file, which is the most important aspect of private IMHO.

> The vast majority of the time, if I am working in a file I want to be able to access everything in that file. I think this is a phenomenal mental model to have. It is extremely simple, it covers the most common use cases perfectly, and it should be the soft default.

I agree with you. But that soft-default requires a simple and recognisable name. That’s why I proposed SE-0159. But it got rejected. If we accept that fact, this proposal now attempts to give private back its original intent as a soft-default. It’s not the access model I would have preferred, but its better in my opinion than the current status-quo.

> To the extent that we want to support protecting things within a file, it is most beneficial to mark those declarations with a lengthy, unmistakeable blazon. That way when you are reading code and come across something like “fragilelocallyscoped var doNotBreakThisInvariant” you know that you must be extra cautious about modifying it. In particular, such invariant-sensitive items should not use the same keyword as other members, because if they did there would be no warning sign for them.
> 
> Let me be abundantly clear: when someone is working in a file, they can always change the access level of members if necessary. In order to protect invariants, scoped visibility must very clearly inform readers that *this item should not be touched* except via dedicated channels, and that its visibility *should not be changed* as well. To convey that, those declarations need to be distinct and unmistakable.
> 
> If you are reading through a file with many “private” declarations and one or two “dangerproceedwithcaution” declarations, you are much more likely to think twice before widening an access level in a potentially invariant-breaking way than if they were all just “private”.
> 
> So, if we are going to keep scope-based visibility at all, it should *definitely not* be spelled “private”. A longer, more-explicit keyword that stands out prominently would be best, though nearly anything including “scoped” would suffice as long as it is different from “private”.
> 
> We *must not* spell the invariant-protecting, danger-warning access level “private”.
> 
> Leaving it as it is now would be *actively harmful*. Swift 4 is our last realistic chance to get this right. We made a mistake in Swift 3. For our own sake, and for the sake of the Swift language and its evolution process, please let us fix this.

The Core Team has said they will not consider renaming private. End of story. It’s not worth discussing something that has *no* chance of being accepted. As John McCall said:

I agree that we shouldn't have done it, but:

> I hope the core team will reconsider the spelling change to “private” and “scoped”.


We won't.

John.

> We can simultaneously solve the problem, retain scoped visibility, and restore the file-level meaning of “private”, simply by changing the spelling of two keywords. The core team’s reason for disfavoring that approach, namely “churn”, is easily overcome, as they themselves noted, by a fully automated migrator.
> 
> Nevin
> _______________________________________________
> 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/0107e2da/attachment.html>