> On Apr 11, 2017, at 10:39 PM, Chris Lattner via swift-evolution > <[email protected]> wrote: > > However, as of the core team meeting last week, it became clear that the > priority of maintaining source stability (and thus, not massively thrashing > source files in the 3->4 conversion) is an overriding concern.
Okay. I stand by my previous opinion that SE-0169 should be rejected. If we are to have two sub-file access levels, they should be highly differentiated so that they can serve different use cases. Scoped `private` serves very different use cases from `fileprivate`; SE-0169's `private` is basically a poor imitation of `fileprivate`. Moreover, I think SE-0169's change to `private` would be just as disruptive as aliasing `private` to `fileprivate` (but keeping `fileprivate` and not changing any keywords in migration); it's simply easier to "sell" to people who are unhappy with the disruption. If I believed that SE-0169 would make the language better, I would support it. If I believed that it was not as good as aliasing `private` and `fileprivate`, but genuinely would be easier for users to migrate, I would support it. But it really seems to me that its only advantage over `private`-`fileprivate` aliasing is that it will give us an excuse for the change instead of only being able to say "We made a mistake in Swift 3 and we're sorry". I don't think the long-term costs of having two similar-but-not-the-same access levels are worth the short-term gain of avoiding this criticism. So I believe we should reject SE-0169 and instead change our documentation to recommend use of `fileprivate` unless `private` is specifically required. We should then freeze the access control design, with the possible exception of an additive submodule feature. (And also decree that uttering the words "I propose that we change the private keyword" shall be punished by drawing and quartering.) -- Brent Royal-Gordon Architechies
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
