[swift-evolution] [Draft] Fix Private Access Levels

Jonathan Hull jhull at gbis.com
Wed Feb 22 01:37:28 CST 2017

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).


> On Feb 21, 2017, at 2:41 PM, Xiaodi Wu via swift-evolution <swift-evolution at 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.

More information about the swift-evolution mailing list