[swift-evolution] [Review] SE-0159: Fix Private Access Levels
david at alkaline-solutions.com
Mon Mar 20 19:19:22 CDT 2017
> 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?
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution