[swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Michel Fortin]

> Le 23 mars 2017 à 12:03, Matthew Johnson via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> I think it’s likely that a non-trivial degree of any confusion is related to the mistake we made in choosing the names.  Both `fileprivate` and `private` include the word `private` in their name.  If we had left `private` alone and introduces scoped access with the name `scoped` I think the difference would have been much more clear to most people who have been confused.

An interesting question when digging into the past is: would the core team have accepted the "scoped" proposal knowing what we know today? It's hard to judge form the outside how much the acceptance of scoped-private by the core team at that time was linked to it being able to replace most instances of file-private, but I'm under the impression that it was the tipping point.

The current proposal, as written, is to return to the Swift 2 model, making it as if the initial `scoped` proposal for Swift 3 had been rejected. Which brings another interesting question: let's assume for a moment that this proposal to revert to the Swift 2 model is accepted as is... should we also backtrack on the idea of allowing `public` members inside of `private` classes? As I remember, this was added to Swift 3 to make it possible to have `fileprivate` members inside of `private` types. This proposal leaves this unchanged though, which means it's not a complete revert to the Swift 2 model. Is this an oversight? Maybe it'd break source compatibility a bit too much.

-- 
Michel Fortin
https://michelf.ca