> On Mar 20, 2017, at 5:54 PM, Douglas Gregor via swift-evolution
> <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution