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

Carl Brown1 Carl.Brown1 at ibm.com
Thu Mar 23 20:26:20 CDT 2017

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:
> Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at
> https://lists.swift.org/mailman/listinfo/swift-evolution<
> or, if you would like to keep your feedback private, directly to the
review manager. When replying, please try to keep the proposal link at the
top of the message:
> Proposal link:
> Reply text

> What is your evaluation of the proposal?

-1. No.  Please don't remove a useful feature and break existing code in
thousands of places just to prevent some confusion due to the similarity of
two keywords.

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

No. Not at all.

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

No. This explicitly removes a feature that the community uses and takes us
back to Swift 2.2. That's literally the opposite of the "direction of

> If you have used other languages or libraries with a similar feature, how
do you feel that this proposal compares to those?

I've used a number of different languages with various scoping and access
modifiers, and there is enough variation in other languages that there's no
clear requirement that Swift should agree with any other languages' usage.

> How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

I reviewed the usage of `private` and `fileprivate` in the
swift-corelibs-foundation and swift-corelibs-libdispatch repositories.
There are 500+ instances across those two repositories (386 private and 131
fileprivate on the version of those libraries I already had checked out on
my laptop to work on the bug I'm currently chasing).

To be honest, the open-source version of Foundation still has a long way to
go to get the level of quality of the existing Objective-C frameworks, and
we already have enough work to do without having to go make a bunch of
arbitrary changes and risk a bunch of regressions because someone doesn't
like a keyword.  This is a source-breaking change, and we need to stop
making source-breaking changes unless they're absolutely necessary, and
this is far from absolutely necessary.

Accepting this proposal would waste hundreds of person-hours of work and
cause even more confusion than it's trying to prevent by causing tons of
existing online documentation, tutorials and answered questions to be
rendered incorrect.

I vote "No".


Carl Brown
Swift at IBM
Carl.Brown1 at IBM.com (Work)
CarlB at POBox.com (Home)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170323/ba39d475/attachment.html>

More information about the swift-evolution mailing list