[swift-evolution] [Review] SE-0159: Fix Private Access Levels

[David Waite]

> On Mar 20, 2017, at 5:54 PM, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hello Swift community,
> 
> The review of SE-0159 "Fix Private Access Levels" begins now and runs through March 27, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md <https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md>
> What is your evaluation of the proposal?
I’m conflicted. This is generally better than the current state, but I worry that we may want to change access levels in an incompatible way yet again in the future.

The problem isn’t with private as defined today, but that there is a desire for access control levels in between private and internal. 

My opinion - the biggest issue with fileprivate is that it is close enough to not have a clear distinction of *why* a developer would choose fileprivate over private - the distinction is left meaningless unless defined for the project as part of coding standards.

In many languages, a scoped “private" has a clear meaning - protecting methods and state which could cause an external party to misuse the type - break class invariants, break threading model, and so on.

The reverted “private” does not have that meaning - extensions and other types within the same file have the ability to misuse the type to break all the above.

For that reason, I think it is important in evaluation to decide just how important a scoped “private” protecting type internal code. If it is important, I’d recommend deferring making this change, and instead shoot for a future where ‘private' remains the same but ‘fileprivate’ is replaced with something more powerful.

> Is the problem being addressed significant enough to warrant a change to Swift?
Yes

> Does this proposal fit well with the feel and direction of Swift?

As stated in the evaluation above, I believe this is dependent on whether submodules, multi-module frameworks, or friend access will modify access control in the future. In that case, I worry that we would actually prefer having the scoped private in concert with the new access modifiers, and would recommend deferring change.

> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
In-depth study/lots of arguing and use of the existing (and Swift 2) system

-DW
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170320/911373da/attachment.html>