[swift-evolution] [Draft] Fix Private Access Levels
david at hartbit.com
Wed Feb 22 01:47:43 CST 2017
> On 22 Feb 2017, at 08:37, Jonathan Hull <jhull at gbis.com> wrote:
> 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).
I saw this but it looks very confusing for me: private would mean different things in different contexts and I would have no way to make things private to a file in a submodule.
>> 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