> Le 23 mars 2017 à 12:03, Matthew Johnson via swift-evolution > <[email protected]> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
