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

[Jonathan Hull]

> On Feb 21, 2017, at 11:47 PM, David Hart <david at hartbit.com> wrote:
> 
> 
> 
>> 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.

Nor would you have a way to make things private to a particular scope. Private would always mean private to the submodule (and files without an explicit submodule would be an implicit anonymous submodule). I like the simplicity.  You can basically think of it as Swift 2 private, but with the allowance to split things up into multiple files.

Anyway, my main point (regardless of what people think of that particular proposal) is that we need to fix the underlying issues with access (not just rehash 0025).

Thanks,
Jon

>> Thanks,
>> Jon
>> 
>>> 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.
>> 
> 
>