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

[Xiaodi Wu]

I agree with critiques that the proposal text itself could use some
fleshing out. There are a number of statements made that could use more
context; while it is true that a lot of that context already exists in the
form of messages to this list, in an ideal world someone would have time to
collate into the proposal the most convincingly argued points on both sides
of the debate.

That said, the proposed solution itself is succinct, unambiguous, and
easily understood. It does not argue that the new access level in Swift 3
has no merit, but rather that it has defects sufficient to merit a reversal
to what we had before. The migration path is clear and unlikely to cause
major problems. Therefore, as I agree with the arguments, I support the
proposal.

As to Drew's excellent analysis--

The statements about defaults is not strange. The core team itself, in its
rationale for accepting SE-0025, said that the design "makes 'private' the
'safe default' for cases where you don't think about which one [i.e.
`fileprivate` vs. `private`] you want to use." The current proposal is
simply engaging with the language and thinking of the core team.

The data presented are very helpful. But, I interpret the data differently.
Based on the extended table, I see that `fileprivate` becomes increasingly
indispensable the more you code in a style that uses extensions. In
codebases that have a very small number of extensions, the ratio of
`fileprivate` to `private` is heavily skewed in favor of the latter.
However, in codebases that have dozens of extensions, the ratio of
`fileprivate` to `private` draws closer to 1:3 or 1:2. This goes to a very
important basis on which the original proposal (SE-0025) was decided: the
core team predicted that `fileprivate` would be rarely used in idiomatic
Swift with the introduction of a new `private`. As I understand it, the
idea was that most users would not have to contend with four access
modifiers (now five) to become proficient in Swift but rather only three.
`fileprivate`, therefore, could be named awkwardly based on the expectation
that it would be rarely seen.

However, real-world experience now demonstrates that `fileprivate` is *not*
rarely seen. In fact, as the data above bear out, it is very hard not to
use `fileprivate` when writing code in at least one very common Swift style
(i.e. using same-file extensions). The point is well taken--but in the end
it isn't germane to the argument--that *some* styles of Swift code do not
have to use `fileprivate`. The point is that the core team's acceptance of
the design was based on a prediction that did not turn out to be true:
namely, that idiomatic Swift would rarely need `fileprivate`. As a
consequence, more users now have to contend with more access modifiers than
anticipated.

I disagree that there needs to be much more said about "complexity"--it is
self-evident that four access modifiers are more complex than three. (And
yes, I agree with previous arguments on this list that only two access
modifiers are really necessary at all: internal and public.)

Charles Srstka's added comment, while intriguing, poses a problem in
argumentation. One of the points being made above about the major advantage
of new `private` over `fileprivate` is precisely that new `private` is
invisible to extensions. If one "solves" the problem of having to use
`fileprivate` by making `private` visible to extensions, it may well be the
case that `fileprivate` is no longer commonly necessary--but one has also
reverted one of the major arguments in favor of new `private` in the first
place. And if `fileprivate` becomes uncommon but still strictly necessary
(as it would be a broader level than any newly invented `private` that is
exposed to extensions, we would still have to keep both access modifiers
around since the former cannot be migrated to the latter), thus juggling
access modifiers without simplifying anything.


On Mon, Mar 20, 2017 at 11:31 PM, Rob Mayoff via swift-evolution <
swift-evolution at swift.org> wrote:

> I also disagree with the proposal, and Drew's explanation is spot on.
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170321/3fb2c4c5/attachment.html>