<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>As to Drew's excellent analysis--</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.)</div><div><br></div><div>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.</div><div><br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 20, 2017 at 11:31 PM, Rob Mayoff via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">I also disagree with the proposal, and Drew's explanation is spot on.<div class="gmail_extra"><br></div></div>
<br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div></div></div></div>