> On 4 Apr 2017, at 19:21, Nevin Brackett-Rozinsky via swift-evolution > <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
