I fully agree. I actually think that applies to both solutions though. As much as I would like to see the mess around private fixed, I think it needs to be as part of a well considered redesign of the access system that adds enough functionality to stop this cycle. We can’t just rename things or flip back and forth between options every 6 months.
As an example of what I think *is* an appropriate change is Nevin’s suggestion on another thread to add a single level of submodules (which group files). As part of this change, ‘private’ would mean private to the submodule (or file if the file is not part of a submodule). Internal/Public/Open would remain unchanged. Thus you have only private, internal, and public/open… but the fix came as part of unifying with other improvements (and is not just returning to pre-0025). Thanks, Jon > On Feb 21, 2017, at 2:41 PM, Xiaodi Wu via swift-evolution > <swift-evolution@swift.org> wrote: > > Well-written as-is. > > Overall, my feedback is that solution 2 should not be on the table (though > there are people who clamor for it), and not because I don't agree with it. > However, simply as a matter of following an appropriate process, solution 2 > was originally proposed in SE-0025, fully considered, and modified by the > core team to the current design. One can disagree whether `scoped` is more > appropriate than `private` as a name for that access modifier, and one is > likely to say that `private` looks nicer than `fileprivate`, but that's > neither here nor there. The appropriateness or niceness of these terms is > unchanged from last year. Re-submitting SE-0025 cannot be the solution for > fixing SE-0025. _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
