<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 21, 2017, at 9:28 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">On Tue, Mar 21, 2017 at 8:31 PM, Matthew Johnson <span dir="ltr" class=""><<a href="mailto:matthew@anandabits.com" target="_blank" class="">matthew@anandabits.com</a>></span> wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div class=""><br class=""><br class="">Sent from my iPad</div><div class=""><div class="h5"><div class=""><br class="">On Mar 21, 2017, at 7:40 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">On Tue, Mar 21, 2017 at 6:44 PM, Drew Crawford <span dir="ltr" class=""><<a href="mailto:drew@sealedabstract.com" target="_blank" class="">drew@sealedabstract.com</a>></span> wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><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 style="word-wrap:break-word" class=""><div id="m_3003716928823358062gmail-m_-4816332181787402365bloop_customfont" style="margin:0px" class=""><span class="m_3003716928823358062gmail-"><div style="font-family: helvetica, arial; font-size: 13px;" class=""><blockquote type="cite" class="m_3003716928823358062gmail-m_-4816332181787402365clean_bq" style="font-family:helvetica,arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">I am confused by this response. An argument in _support_ of new `private` was that it is more in line with expectations of users coming from other languages. In other some cases, such an argument might have its place. However, as others have pointed out on this list, those other languages don't have facilities like Swift's extensions, and therefore it was not a very strong argument for new `private` to say that it better aligns with user expectations coming from other languages.</div></div></div></blockquote></div></span><p style="font-family: helvetica, arial; font-size: 13px;" class="">The underlying issue here (which I have now identified, thanks!) is what motivates the use of extensions. That question predates proposals, but the Swift book provides the following motivation, which I have numbered for ease of reference:</p><div class=""><blockquote type="cite" style="font-family:helvetica,arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;border-width:1px;padding-left:5px;border-left-color:rgb(0,64,128)" class="">1. Extensions add new functionality to an existing class, structure, enumeration, or protocol type. </blockquote><blockquote type="cite" style="border-width:1px;padding-left:5px;border-left-color:rgb(0,64,128)" class=""><div id="m_3003716928823358062gmail-m_-4816332181787402365bloop_customfont" style="margin:0px" class=""><p class="">2. This includes the ability to extend types for which you do not have access to the original source code (known as retroactive modeling). </p><p class="">3. Extensions are similar to categories in Objective-C.</p></div></blockquote></div><div class="">It seems to me this motivation contemplates use “at some distance”, that is we intend to create some semantically meaningful separation between the declaration and the extension(s). If we did not we could use MARK or some other comment-based scheme to organize our class.</div><div class=""><br class=""></div><div class="">2 is explicitly at great distance, so we know the distance motivation is well within scope. 1 refers to “an existing” type which implies a certain level of functionality in the unextended type, and not merely a partial implementation in the unextended type. The record on 3 is more mixed (ObjC programmers do occasionally use categories “closely-held” to group a few methods together). However ObjC also has the “distance” tradition: categories cannot introduce new storage even when this is technically trivial (within the same compilation unit for example), and this tradition was continued under Swift with the new ABI.</div><div class=""><br class=""></div><div class="">What I am suggesting is that the primary design purpose of an extension is to create semantic distance between a declaration and the functionality being added.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I'm not sure it is necessary for extensions to have a "primary design purpose." They serve many purposes. One use I have for them is as follows:</div><div class=""><br class=""></div><div class="">```</div><div class="">struct A {</div><div class=""> // Stuff here constitutes the "raison d'etre" for A.</div><div class="">}</div><div class=""><br class=""></div><div class="">extension A : B {</div><div class=""> // In the course of implementing `A`, I have discovered that</div><div class=""> // `A` can fulfill the semantic guarantees of `B`, and in fact</div><div class=""> // fulfills most of them already.</div><div class=""> //</div><div class=""> // So, I conform to B, as in so doing there are some practical</div><div class=""> // advantages, such as gaining some default implementations.</div><div class=""> //</div><div class=""> // But, to conform, I may need to implement some methods</div><div class=""> // not really essential for a functional `A`, but required nonetheless</div><div class=""> // to conform to `B`.</div><div class=""> //</div><div class=""> // I implement them here in an extension; in so doing, I express</div><div class=""> // the idea that I have, after implementing `A`, discovered its</div><div class=""> // conformance to `B`, and I am here supplying the remaining</div><div class=""> // implementations necessary for that conformance.</div><div class=""> //</div><div class=""> // That is, if `B` did not exist, neither would these functions here.</div><div class=""> // But there may be some requirements of `B` that would be</div><div class=""> // implemented in `A` whether or not `B` exists.</div><div class=""> // Those are implemented above, in `struct A { ... }`.</div><div class="">}</div><div class="">```</div><div class=""><br class=""></div><div class="">I find this to be an eloquent way to separate concerns. It is a common pattern encouraged by code I admire written by others more skilled than me in Swift.</div><div class=""><br class=""></div><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 style="word-wrap:break-word" class=""><div id="m_3003716928823358062gmail-m_-4816332181787402365bloop_customfont" style="margin:0px" class=""><div class="">A mechanism to hide variables from extensions is something that *furthers* this design goal of extensions, rather than contradicts it.</div></div></div></blockquote><div class=""><br class=""></div><div class="">This, I suppose, is an argument for you to take up with Charles.</div><div class=""> </div><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 style="word-wrap:break-word" class=""><div id="m_3003716928823358062gmail-m_-4816332181787402365bloop_customfont" style="margin:0px" class=""><div class=""></div><div class="">I understand that some people use extensions as sort of an imitation “partial class” but they simply aren’t (no storage) and we should introduce a new feature if we want to have them.</div><span class="m_3003716928823358062gmail-"><div class=""><br class=""></div><div class=""><blockquote type="cite" style="border-width:1px;padding-left:5px;border-left-color:rgb(0,64,128)" class=""><div id="m_3003716928823358062gmail-m_-4816332181787402365bloop_customfont" style="margin:0px" class="">A core team member (I'm blanking on who) has pointed out that, in the end, the only necessary access modifiers are public and not public (spelled "internal" in Swift).</div></blockquote></div><div class=""><div style="margin:0px" class=""><br class=""></div></div></span><div style="margin:0px" class="">It is not clear to me how this squares with the decision in SE-0025 that other access modifiers were necessary. Can you clarify?</div></div></div></blockquote><div class=""><br class=""></div><div class="">Why do you think SE-0025 decided that other access modifiers are necessary? It merely decided that having four was deemed, on balance, superior to having three. But the minimum number of access modifiers is, by definition, two. In the case of Swift those essentially have to be at the module boundary. Anything more finely diced than that and you are balancing expressivity and complexity. I would not be opposed, incidentally, to stripping back access modifiers to two: `internal` (or maybe eliminate that explicit annotation altogether) and `public`.</div><div class=""><br class=""></div><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 style="word-wrap:break-word" class=""><div id="m_3003716928823358062gmail-m_-4816332181787402365bloop_customfont" style="margin:0px" class=""><div style="margin:0px" class=""><span class="m_3003716928823358062gmail-"><blockquote type="cite" style="border-width:1px;padding-left:5px;border-left-color:rgb(0,64,128)" class=""><div id="m_3003716928823358062gmail-m_-4816332181787402365bloop_customfont" style="margin:0px" class=""><div style="margin:0px" class="">When new `private` and `fileprivate` were shipped, there were numerous questions asked by users on forums such as Stack Overflow</div></div></blockquote></span><div class=""><div style="margin:0px" class=""><div style="margin:0px" class=""><br class=""></div><div style="margin:0px" class="">And before they were shipped, there were people asking for a scoped modifier.</div></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">No, I'm not talking about "asking for"; I'm talking about "asking"--as in, "I don't get it, please explain." The point is that the distinction between `private` and `fileprivate` is not an intuitive one.</div><div class=""> </div><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 style="word-wrap:break-word" class=""><div id="m_3003716928823358062gmail-m_-4816332181787402365bloop_customfont" style="margin:0px" class=""><div style="margin:0px" class=""><div class=""><div style="margin:0px" class=""><div style="margin:0px" class="">And when we change them again, what questions will that generate? So I don’t see what we are accomplishing with this line of inquiry.</div><span class="m_3003716928823358062gmail-"><div style="margin:0px" class=""><br class=""></div><div class=""><blockquote type="cite" style="font-family:helvetica,arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;border-width:1px;padding-left:5px;border-left-color:rgb(0,64,128)" class=""><div id="m_3003716928823358062gmail-m_-4816332181787402365bloop_customfont" style="margin:0px" class=""><div style="margin:0px" class=""><div style="margin:0px" class=""><div style="margin:0px" class="">You see the new access modifiers described, for example, as something that "take[s] some getting used to." Rather damning as a euphemism, don't you think? </div></div></div></div></blockquote></div></span><p class="">Not at all. We could describe strong typing, or optionals, enums, pattern matching, etc., in this way. ARC in particular is “difficult to teach” but we should not get rid of it, it solves a safety problem. A scoped access modifier is similar.</p></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Again, the argument is not that scoped access modifiers have _no_ merits or that it solves _no_ problems; it is that its merits are greatly outweighed by its drawbacks, or that the problems solved are not more pressing than the problems introduced, which include problems in learning and teaching Swift.</div><div class=""><br class=""></div><div class="">Swift promises only one type of safety by default: memory safety. ("Swift is a high-performance system programming language. It has a clean and modern syntax, offers seamless access to existing C and Objective-C code and frameworks, and is memory safe by default.")</div><div class=""><br class=""></div><div class="">Since ARC helps to deliver two indispensable promises ("seamless access to...Objective-C" and "memory safe by default"), that weighs heavily in its favor despite difficulty of learning and teaching. `fileprivate` is, I think you'll agree, certainly not a clean and modern syntax, and its presence or absence has little to do with the other tentpole promises of Swift.<br class=""></div><div class=""><br class=""></div><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 style="word-wrap:break-word" class=""><div id="m_3003716928823358062gmail-m_-4816332181787402365bloop_customfont" style="margin:0px" class=""><div style="margin:0px" class=""><div class=""><div style="margin:0px" class=""><span class="m_3003716928823358062gmail-"><blockquote type="cite" style="border-width:1px;padding-left:5px;border-left-color:rgb(0,64,128)" class=""><p class="">When the Swift core team approved the proposal, they expressed the belief that `fileprivate` would be rarely used. This has turned out plainly and indisputably not to be true. It is clear that they expected Swift to have, after SE-0025 (and before `open`), three commonly used access modifiers and one vestigial one. Instead we have four/five commonly used access modifiers. Thus, the complexity of the current system is _not_ what was envisioned at the time of approval for SE-0025, and the resulting system should be re-evaluated in light of this real-world data. </p></blockquote></span><div class=""><p class="">The only citation I can find on this topic is the cryptic “<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160328/013829.html" target="_blank" class="">fileprivate is rarely needed</a>” in the context of “rare enough to be explicit”. I submit that according to previously-presented data, I do use it rarely, less often than the other modifiers, certainly in a manner consistent with being explicit. I do not see how we jump from that fact pattern to “plainly and indisputably… _not_ what was envisioned at the time”. It is not plain and I do dispute it.</p></div></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">*You* may indeed write in a style that uses it rarely. I think you see from even this conversation that others do not code in such a style. There are 183,000 results for `fileprivate` on Google, which is in the same ballpark as results for `associatedtype`. Compare with 60,800 for `precedencegroup` and 1430 for `<wbr class="">ExpressibleByStringInterpolati<wbr class="">on`.</div><div class=""><br class=""></div><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 style="word-wrap:break-word" class=""><div id="m_3003716928823358062gmail-m_-4816332181787402365bloop_customfont" style="margin:0px" class=""><div style="margin:0px" class=""><div class=""><div style="margin:0px" class=""><div class=""><span class="m_3003716928823358062gmail-"><blockquote type="cite" style="border-width:1px;padding-left:5px;border-left-color:rgb(0,64,128)" class=""><p class="">The code above should compile and does not.</p></blockquote></span></div><div class=""><p class="">It is not clear to me how this is especially relevant. The point of a scoped access modifier is to prevent programs from compiling when they should not. Here is a program that does not compile when it should; that’s a bug, but it doesn’t go to whether the scoped people are caught with their pants down or working from bad safety assumptions. It’s just a complier crasher.</p></div></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">It is relevant because this is not some corner case; it's not some fuzzed nonsense like `{{<<var;;` that happens to crash the parser. It is a tentpole feature of `private` proposed in SE-0025 that shipped broken in 3.0 and will ship broken in 3.1. In other words, SE-0025 has not been completely implemented, and if ABI stability is declared before it is fixed, it may not even be completely implementable.</div><div class=""> <br class=""></div><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 style="word-wrap:break-word" class=""><div id="m_3003716928823358062gmail-m_-4816332181787402365bloop_customfont" style="margin:0px" class=""><div style="margin:0px" class=""><div class=""><div style="margin:0px" class=""><div class=""><span class="m_3003716928823358062gmail-"><blockquote type="cite" style="border-width:1px;padding-left:5px;border-left-color:rgb(0,64,128)" class=""><p class="">(a) even proponents of new `private` disagree on one of two key goals stated for new `private`;</p></blockquote></span></div><div class=""><p class="">I suspect that not everyone will agree on the three stated goals for extensions either, but I do not with to remove them.</p></div></div></div></div></div></div></blockquote><div class="">TSPL is not the document of record for goals for extensions, it's a pedagogical tool. By contrast, SE-0025 is the document of record for goals for the new `private`. They may not be *your* goals for `private`, but they are *the Swift community's* goals for `private`, and they have not been met.<br class=""></div><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 style="word-wrap:break-word" class=""><div id="m_3003716928823358062gmail-m_-4816332181787402365bloop_customfont" style="margin:0px" class=""><div style="margin:0px" class=""><div class=""><div style="margin:0px" class=""><div class=""><p class="">I wish to improve them, and a scoped access modifier is one of the tools we have to do that.</p><span class="m_3003716928823358062gmail-"><div class=""><blockquote type="cite" style="font-family:helvetica,arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;border-width:1px;padding-left:5px;border-left-color:rgb(0,64,128)" class="">As far as I can see, in that example, you can rename `private func prune` to `private func _prune` and have no further problems. That is to say, the workaround is a single character at each use site, which by your metric makes this proposal half as onerous as removing `++`.</blockquote></div></span><p class="">The problems are described in SE-0025:</p><div class=""><blockquote type="cite" style="font-family:helvetica,arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;border-width:1px;padding-left:5px;border-left-color:rgb(0,64,128)" class="">> Another, less reliable, way is to prefix APIs that are meant to be hidden with a _ or do something similar. That works, but it’s not enforced by the compiler, and those APIs show up in tools like code completion, so the programmer has to filter out the noise — although these tools could quite easily support hiding methods with the _ prefix standard. Also, there is a greater danger of using private APIs if they do something similar to public APIs but are somehow more optimized (because they make additional assumptions about the internal state).</blockquote></div><p class="">In any case, this workaround is not “semantically equivalent” and so regardless of the number of characters it is different than ++ or var.</p></div></div></div></div></div></div></blockquote><div class="">I'm not sure how the quotation describes a semantic issue; it describes a practical drawback with respect to code completion. And it's correct. Again, I'm not saying that there are no merits to a scoped access level. I'm just saying that a tidier code completion menu and not writing `_` aren't in themselves compelling. The workaround after removal is totally transparent to the end user, and all uses of a non-public API in the same file can be trivially audited to prove that they aren't called at unintended places, so I'm not sure why you think some bar of "semantic equivalence" needs to be met.</div></div></div></div></div></blockquote><div class=""><br class=""></div></div></div><div class="">Uses in a single file at a single point in time can be audited trivially. Ensuring correct use all (scope)private variables in all files of a large project over a span of years is not so trivial. This kind of mistake can slip through code review even on diligent team. The compiler guarantee has significant value in these contexts.</div></div></blockquote><div class=""><br class=""></div><div class="">Certainly, I'm not arguing that it doesn't have its benefits. But if it slips through code review, what goes wrong? </div></div></div></div></div></blockquote><div><br class=""></div><div>Bugs of various sorts. I have seen this very thing happen recently in Swift 2.3 code.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">And couldn't this be enforced by a linter feature that warns if a private member beginning with _ is accessed outside of scope?</div></div></div></div></div></blockquote><div><br class=""></div><div>I don’t like to use naming conventions and linters to catch things that belong in the language proper. Hasn’t the community agreed that we don’t want dialects of Swift?</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div class=""><div class="h5"><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> </div><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 style="word-wrap:break-word" class=""><div id="m_3003716928823358062gmail-m_-4816332181787402365bloop_customfont" style="margin:0px" class=""><div style="margin:0px" class=""><div class=""><div style="margin:0px" class=""><div class=""><div class="m_3003716928823358062gmail-h5"><div style="margin:0px" class="">On March 21, 2017 at 5:26:47 PM, Xiaodi Wu (<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>) wrote:</div></div></div></div></div></div></div><div class=""><div class="m_3003716928823358062gmail-h5"> <blockquote type="cite" class="m_3003716928823358062gmail-m_-4816332181787402365clean_bq"><span class=""><div class=""><div class=""></div><div class="">
<div dir="ltr" class="">On Tue, Mar 21, 2017 at 3:59 PM, Drew Crawford via
swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class="">
<div class="gmail_extra">
<div class="gmail_quote">
<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 style="word-wrap:break-word" class="">
<div id="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="font-family: helvetica, arial; font-size: 13px; margin: 0px;" class="">
<blockquote type="cite" style="border-width:1px;padding-left:5px;border-left-color:rgb(0,64,128)" class="">
<span class="m_3003716928823358062gmail-m_-4816332181787402365gmail-"><span style="font-family:'helvetica neue',helvetica;font-size:14px" class=""> The
arguments for the revert are in the proposal and in the discussions
in this thread.</span></span></blockquote>
</div>
<div class=""><br class=""></div>
What is in the proposal and this thread are a set of opinions,
e.g.<br class="">
<div class=""><br class=""></div>
<div class="">* "the access level change of SE-0025 was met with
dissatisfaction by a substantial proportion of the general Swift
community."<br class="">
<div id="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign_1490122739579070976" class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign">* "Those changes can be
viewed as actively harmful,”</div>
<div id="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign_1490122739579070976" class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign">* "it is extremely common
to use several extensions within a file.”</div>
<div id="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign_1490122739579070976" class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign">* “[existing regime]
encourages overuse of scoped access control”</div>
<div id="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign_1490122739579070976" class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign">* “[fileprivate is the]
more reasonable default”</div>
<div class=""><br class=""></div>
I am asking for the arguments or evidence that led you or others to
these opinions. I understand that you and others believe
them, but you understand that they are now a matter of debate. We
are not going to reach any mutual understanding just asserting
things we believe. The underlying evidence is what would be
necessary to convince others to our point of view. I am
trying to ascertain what that evidence is.</div>
<div class=""><span class="m_3003716928823358062gmail-m_-4816332181787402365gmail-"><br class=""></span></div>
<div class="">
<blockquote type="cite" style="border-width:1px;padding-left:5px;border-left-color:rgb(0,64,128)" class="">
<span class="m_3003716928823358062gmail-m_-4816332181787402365gmail-">> It has pointed quite a few times by core
team members that comparison to languages is not a very strong
arguments, </span></blockquote>
</div>
<div class=""><span class="m_3003716928823358062gmail-m_-4816332181787402365gmail-"><br class=""></span></div>
<div class="">The context here is that you presented an argument that
Swift’s “private” was confusing to users of other languages:</div>
<div class=""><span class="m_3003716928823358062gmail-m_-4816332181787402365gmail-"><br class=""></span></div>
<div class=""><span class="m_3003716928823358062gmail-m_-4816332181787402365gmail-"><span style="color:rgb(10,81,161);font-family:'normal helvetica',sans-serif" class="">>
In most languages, that keyword is “private” so its valid to say
that newcomers to the language will “default” to using that
one. </span></span></div>
<div class=""><br class=""></div>
<div class="">If you no longer think that argument is strong because it
relies on a comparison to other languages, then we agree :-)
But in that case we lose an argument for this proposal.
The reason we are talking about other languages is because that was
an argument advanced to support the proposal.</div>
<div class=""><span class="m_3003716928823358062gmail-m_-4816332181787402365gmail-"><br class=""></span></div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">I am confused by this response. An argument in _support_ of
new `private` was that it is more in line with expectations of
users coming from other languages. In other some cases, such an
argument might have its place. However, as others have pointed out
on this list, those other languages don't have facilities like
Swift's extensions, and therefore it was not a very strong argument
for new `private` to say that it better aligns with user
expectations coming from other languages.</div>
<div class=""> </div>
<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 style="word-wrap:break-word" class="">
<div class="">
<blockquote type="cite" style="border-width:1px;padding-left:5px;border-left-color:rgb(0,64,128)" class="">
<span class="m_3003716928823358062gmail-m_-4816332181787402365gmail-">> Some people used the for(;;) loop, the ++
operator, var parameters.</span></blockquote>
</div>
<div class=""><span class="m_3003716928823358062gmail-m_-4816332181787402365gmail-"><br class=""></span></div>
<div class="">In those cases, there was extensive discussion of how to
achieve the things people were achieving with those features with
alternative patterns. var parameters for example have a 1LOC
workaround to achieve the previous semantics, ++ had two
characters, for(;;) was slightly trickier but we had a clear
concept of the scope of the impact. So far as I’m aware, the only
suggestion to people who currently use a scoped access modifier is
to stop having their problems.</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">You've given one example of code that takes advantage of new
`private`. As far as I can see, in that example, you can rename
`private func prune` to `private func _prune` and have no further
problems. That is to say, the workaround is a single character at
each use site, which by your metric makes this proposal half as
onerous as removing `++`.</div>
<div class=""><br class=""></div>
<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 style="word-wrap:break-word" class="">
<div class="">So the circumstances of earlier removals and this one are very
different.</div>
<div class=""><br class=""></div>
<div class="">
<div class="">
<div class="">
<blockquote type="cite" style="font-family:helvetica,arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;border-width:1px;padding-left:5px;border-left-color:rgb(0,64,128)" class="">
<div class="">> • either a programmer ... will use private as often as
possible</div>
<div class="">> • or a programmer will … use fileprivate all the
time </div>
</blockquote>
</div><p class="">There is also the possibility that a programmer considers which
modifier is appropriate for the code they are writing. You
"argue that... is very rare” but I still am not sure what this
argument is or what led you or others to this conclusion.</p>
</div>
</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">I'm not enamored of the argumentation in the proposal set out
above. But since you are saying that you're not sure how anybody
came to support this proposal, here's how I arrived at supporting
it:</div>
<div class=""><br class=""></div>
<div class="">A core team member (I'm blanking on who) has pointed out that,
in the end, the only necessary access modifiers are public and not
public (spelled "internal" in Swift). It has been my understanding
that supporting all possible ways of hiding a member from arbitrary
other code within the same module is a _non-goal_. There have been
numerous attempts at designing elaborate access modifier schemes
that make this possible with friends, protected, shared,
what-have-you, and I try to bring up this point each time.</div>
<div class=""><br class=""></div>
<div class="">Beyond the two absolutely essential access modifiers, anything
else does not add to safety as the term is understood in Swift, but
rather improves developer experience. But what is gained in terms
of developer experience with each additional access modifier (due
to increased expressiveness) is offset by what is lost due to
complexity. So then the question is: what is the ideal number of
access modifiers? is it two? three? four? five? six? eight? ten?
twelve?</div>
<div class=""><br class=""></div>
<div class="">When new `private` and `fileprivate` were shipped, there were
numerous questions asked by users on forums such as Stack Overflow
(easily googled; just as a single example: <a href="http://stackoverflow.com/questions/39027250/what-is-a-good-example-to-differentiate-between-fileprivate-and-private-in-swift" target="_blank" class="">http://stackoverflow.<wbr class="">com/questions/39027250/what-is<wbr class="">-a-good-example-to-differentia<wbr class="">te-between-fileprivate-and-<wbr class="">private-in-swift</a>),
on blogs (again, easily googled; as a single example: <a href="https://useyourloaf.com/blog/swift-3-access-controls/" target="_blank" class="">https://useyourloaf.c<wbr class="">om/blog/swift-3-access-control<wbr class="">s/</a>),
and messages to this list (including from people not part of the
original discussion but who, on using the feature, found it irksome
enough to join the list and make their voice heard).</div>
<div class=""><br class=""></div>
<div class="">You see the new access modifiers described, for example, as
something that "take[s] some getting used to." Rather damning as a
euphemism, don't you think? Certainly not a ringing
endorsement--</div>
<div class=""><br class=""></div>
<div class="">"How do you like my new haircut?"</div>
<div class="">"It, um, takes some getting used to."</div>
<div class=""><br class=""></div>
<div class="">Others also wrote to say that they were finding it difficult
to *teach* this new scheme to students; you can find such messages
in the list archives. I take this to mean that having four/five
access modifiers (depending on whether you consider `open` to be an
access modifier) to be one too many.</div>
<div class=""><br class=""></div>
<div class="">When the Swift core team approved the proposal, they expressed
the belief that `fileprivate` would be rarely used. This has turned
out plainly and indisputably not to be true. It is clear that they
expected Swift to have, after SE-0025 (and before `open`), three
commonly used access modifiers and one vestigial one. Instead we
have four/five commonly used access modifiers. Thus, the complexity
of the current system is _not_ what was envisioned at the time of
approval for SE-0025, and the resulting system should be
re-evaluated in light of this real-world data.</div>
<div class=""><br class=""></div>
<div class="">So, if four/five access modifiers are too many, which one is
carrying the least weight? Which one could be removed to simplify
the scheme while maintaining the most expressiveness? Which one
doesn't fulfill even its own stated goals? Well, one of the key
goals of `private` was to allow members to be encapsulated within
an extension, hidden even from the type being extended (and vice
versa for members defined in the type). It says so in the first
sentence of SE-0025. As seen above in my discussion with Charles
Srstka, even supporters of `private` disagree with that motivation
to begin with. The kicker is, _it also doesn't work_. Try, for
instance:</div>
<div class=""><br class=""></div>
<div class="">```</div>
<div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: menlo;" class="">
<span style="font-variant-ligatures:no-common-ligatures;color:rgb(186,45,162)" class="">struct</span>
<span style="font-variant-ligatures:no-common-ligatures" class="">Foo
{</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: menlo; color: rgb(186, 45, 162);" class="">
<span style="font-variant-ligatures: no-common-ligatures;" class=""> </span>
<span style="font-variant-ligatures:no-common-ligatures" class="">private</span>
<span style="font-variant-ligatures:no-common-ligatures" class="">var</span>
<span style="font-variant-ligatures: no-common-ligatures;" class="">bar:</span>
<span style="font-variant-ligatures:no-common-ligatures;color:rgb(112,61,170)" class="">Int</span>
<span style="font-variant-ligatures: no-common-ligatures;" class="">{</span>
<span style="font-variant-ligatures:no-common-ligatures" class="">return</span>
<span style="font-variant-ligatures:no-common-ligatures;color:rgb(39,42,216)" class="">42</span>
<span style="font-variant-ligatures: no-common-ligatures;" class="">}</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: menlo;" class="">
<span style="font-variant-ligatures:no-common-ligatures" class="">}</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: menlo; min-height: 13px;" class="">
<br class=""></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: menlo; color: rgb(186, 45, 162);" class="">
<span style="font-variant-ligatures:no-common-ligatures" class="">extension</span>
<span style="font-variant-ligatures:no-common-ligatures;color:rgb(79,129,135)" class="">Foo</span>
<span style="font-variant-ligatures: no-common-ligatures;" class="">{</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: menlo; color: rgb(186, 45, 162);" class="">
<span style="font-variant-ligatures: no-common-ligatures;" class=""> </span>
<span style="font-variant-ligatures:no-common-ligatures" class="">private</span>
<span style="font-variant-ligatures:no-common-ligatures" class="">var</span>
<span style="font-variant-ligatures: no-common-ligatures;" class="">bar:</span>
<span style="font-variant-ligatures:no-common-ligatures;color:rgb(112,61,170)" class="">Int</span>
<span style="font-variant-ligatures: no-common-ligatures;" class="">{</span>
<span style="font-variant-ligatures:no-common-ligatures" class="">return</span>
<span style="font-variant-ligatures:no-common-ligatures;color:rgb(39,42,216)" class="">43</span>
<span style="font-variant-ligatures: no-common-ligatures;" class="">}</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: menlo;" class="">
<span style="font-variant-ligatures:no-common-ligatures" class="">}</span></div>
</div>
<div class="">```</div>
<div class=""><br class=""></div>
<div class="">The code above should compile and does not. If I understood
correctly the explanation from a core team member on this list,
it's unclear if it can be made to work without changing how
mangling works, which I believe impacts ABI and is not trivial at
all. Thus, (a) even proponents of new `private` disagree on one of
two key goals stated for new `private`; (b) that goal was never
accomplished, and making it work is not trivial; (c) no one even
complained about it, suggesting that it was a low-yield goal in the
first place.</div>
<div class=""><br class=""></div>
<div class="">So, I conclude that new `private` needs re-evaluation in light
of real-world implementation and usage experience. I haven't even
mentioned the nuances of `private` in one scope being different
from `private` in the containing scope, requiring distinguishing of
effective access levels from nominal ones--just one more wrinkle in
this whole scheme. I feel that allowing someone to write `private
var foo` instead of `private var _foo // don't call this outside
the type`, when that member isn't vended and can't be seen outside
the file anyway, is a tiny win in comparison to the huge complexity
both of implementation (it's still not correctly implemented and
may not be in time for Swift 4!!!) and of usage.</div>
<div class=""><br class=""></div>
<div class=""><br class=""></div>
<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 style="word-wrap:break-word" class="">
<div class="">
<div class="m_3003716928823358062gmail-m_-4816332181787402365gmail-h5">
<div class=""><p class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257airmail_on">On March 21, 2017
at 1:41:48 PM, David Hart (<a href="mailto:david@hartbit.com" target="_blank" class="">david@hartbit.com</a>) wrote:</p>
<blockquote type="cite" class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257clean_bq">
<div dir="auto" class="">
<div class="">
<div class="">
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class=""><br class=""></span>
<div class=""><span class=""><br class="">
<br class="">
Sent from my iPhone</span></div>
<span class="">On 21 Mar 2017, at 16:57, Drew Crawford <<a href="mailto:drew@sealedabstract.com" target="_blank" class="">drew@sealedabstract.com</a>> wrote:<br class="">
<br class=""></span></div>
<blockquote type="cite" class="">
<div class="">
<div id="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="font-family: helvetica, arial; font-size: 13px; margin: 0px;" class="">
<span class=""><br class=""></span></div>
<div id="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="font-family: helvetica, arial; font-size: 13px; margin: 0px;" class="">
<span class=""><br class=""></span>
<div id="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign_1490109825482707968" class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign">
<div class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_container">
<div class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_frame">
<div id="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="margin:0px" class="">
<div class="">
<blockquote type="cite" class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257clean_bq">
<div style="word-wrap:break-word" class=""><span class="">> I’m not arguing that
it is less or more than a majority. I’m just saying that we’ve seen
a lot of talk against the original change.</span></div>
</blockquote>
</div><p class=""><span class="">This proposal asks us to balance the convenience of one
group (extension-writers) against the existence of another
(scoped-access users). To do that, we need a clear idea of
the composition of both groups.</span></p><p class=""><span class="">“A lot of talk” is not the evidentiary standard to remove
a feature. It was not good enough when we introduced the
feature, that required argument and clear use-cases.</span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div class=""><span class="">"A lot of talk" is not the evidence supporting the
proposal: it's just a warning that something may be very
controversial among the community. The arguments for the revert are
in the proposal and in the discussions in this thread.</span></div>
<span class=""><br class=""></span>
<blockquote type="cite" class="">
<div class="">
<div id="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="font-family: helvetica, arial; font-size: 13px; margin: 0px;" class="">
<div id="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign_1490109825482707968" class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign">
<div class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_container">
<div class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_frame">
<div id="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="margin:0px" class="">
<div class="">
<blockquote type="cite" class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257clean_bq">
<div style="word-wrap:break-word" class=""><span class="">> By default, I did not
mean the syntactic default of the language but the access modifier
users will use “by default” when trying to restrict visibility. In
most languages, that keyword is “private” so its valid to say that
newcomers to the language will “default” to using that
one.</span></div>
</blockquote>
</div><p class=""><span class="">Apologies, but I do not understand the
argument:</span></p>
<ol class="">
<li class=""><span class="">A user wants to restrict visibility (e.g. they are
dissatisfied with “internal”)</span></li>
<li class=""><span class="">The user *chooses* private because of familiarity from
another language</span></li>
<li class=""><span class="">The user is then surprised that their choice of private
indeed restricted the visibility, thus achieving their
goal?</span></li>
</ol>
<div class=""><span class="">What language does the user come from in which “private”
is file-visible? It isn’t Java, C++, or PHP. C#’s
“partial” is the closest I can think of, and it isn’t at all
close.</span></div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">It has pointed quite a few times by core team members
that comparison to languages is not a very strong arguments,
especially when Swift does things differently for a good reason. I
can't stop from quoting Xiaodi from a month back:</span></div>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class=""><span style="background-color:rgba(255,255,255,0)" class="">«The
beauty of Swift 2's access modifiers was that they were based
around files and modules, explicitly rejecting types and scopes as
units for determining visibility.» -- Xiaodi</span></span></div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div id="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="font-family: helvetica, arial; font-size: 13px; margin: 0px;" class="">
<div id="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign_1490109825482707968" class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign">
<div class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_container">
<div class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_frame">
<div id="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="margin:0px" class="">
<div class="">A user who wants a middle-ground visibility would “default” to
“protected”, “friend”, “partial”, or similar. After that does
not compile, they will use google to find a middle-road visibility
keyword, for which the only candidate is “fileprivate”. But
they will not choose “private”, it’s just not a reasonable
expectation of what the keyword means to a new Swift
developer.</div>
<div class=""><br class=""></div>
<div class="">The popularity of private “as a default” is simply because
many users prefer to hide their implementation details as a matter
of routine code hygiene. Redefining private in order to
thwart their code hygiene goal seems extreme.</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">The point is that keeping both private and fileprivate feels
like an un-necessary complication:</div>
<div class=""><br class=""></div>
<div class="">• either a programmer falls on your side of the fence and will
use private as often as possible and relegate to fileprivate when
the design leaves no other choice. At that point it feels like a
language wart.</div>
<div class="">• or a programmer will fall on my side of the fence and use
fileprivate all the time and the language feels like it has an
unnecessary access modifier.</div>
<div class=""><br class=""></div>
<div class="">I'd argue that the cases when a programmer will use both
meaningfully is very rare. As a consequence, we should try to only
keep one. Removing fileprivate is a no-go with extensions so that
leaves us with removing private.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div id="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="font-family: helvetica, arial; font-size: 13px; margin: 0px;" class="">
<div id="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign_1490109825482707968" class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign">
<div class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_container">
<div class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_frame">
<div id="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="margin:0px" class="">
<div class="">I agree with several here (as I did in SE-0025) that our
access modifiers are not well-named. However, that’s not the
proposal in front of us.</div>
<div class=""><br class=""></div>
<div class="">
<div class="">
<blockquote type="cite" class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257clean_bq">
<div style="word-wrap:break-word" class="">> My own statistics in my
projects show the contrary. At best, this shows how divisive this
feature is.</div>
</blockquote>
</div><p class="">This *may* show that, if contrary statistics were presented, but
that hasn’t occurred.</p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div class="">I can generate statistics from my projects if you want. But
it's unnecessary: I haven't used private once since it's
introduction in Swift 3. I don't see the advantages it brings worth
the trouble.</div>
<blockquote type="cite" class="">
<div class="">
<div id="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="font-family: helvetica, arial; font-size: 13px; margin: 0px;" class="">
<div id="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign_1490109825482707968" class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign">
<div class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_container">
<div class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_frame">
<div id="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="margin:0px" class="">
<div class="">
<div class="">
<div class="">
<blockquote type="cite" class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257clean_bq">
<div style="word-wrap:break-word" class="">
<ul class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257MailOutline">
<li class="">In old code, statistics could be biased by the migrator having
replaced all previous instances of private by fileprivate.</li>
</ul>
</div>
</blockquote>
</div><p class="">If the migrator migrated code to private, and it *worked* (e.g.
did not introduce visibility errors) this is not bias, this is a
correct use of the feature.</p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div class="">The migrator migrated to fileprivate everywhere, not private,
disagreeing with your use of fileprivate.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div id="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="font-family: helvetica, arial; font-size: 13px; margin: 0px;" class="">
<div id="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign_1490109825482707968" class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign">
<div class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_container">
<div class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_frame">
<div id="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="margin:0px" class="">
<div class="">
<div class="">
<div class="">
<blockquote type="cite" class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257clean_bq">
<div style="word-wrap:break-word" class="">> I'm just arguing that the
additional scope-based access modifier does not provide enough
differentiation to be worth that complexity.</div>
</blockquote>
</div><p class="">The only argument I have seen so far around “complexity” boils
down to: “some people do not use it”. But some people *do*
use it, and anyway if we are going to remove all the features “not
enough people” use then we are in for a ride.</p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div class="">Some people used the for(;;) loop, the ++ operator, var
parameters. Many other features were removed from Swift to simplify
he language, make it more consistent. Those are worthwhile goals.
Yes, we are past Swift 3 now, but that doesn't mean we shouldn't be
able to propose a few rare breaking proposals. The implementation
of access modifiers came so late in the Swift 3 timeframe that we
had little time to play around with them before Swift 3 was
released. Now that we have, we have a short window of time to fix
mistakes that were made. I'm just arguing that the proposal was one
of those mistakes. But you have a right to disagree.</div>
<blockquote type="cite" class="">
<div class="">
<div id="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="font-family: helvetica, arial; font-size: 13px; margin: 0px;" class="">
<div id="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign_1490109825482707968" class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign">
<div class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_container">
<div class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_frame">
<div id="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="margin:0px" class="">
<div class="">
<div class=""><p class="">Swift 3 shipped, so what we are discussing now is yanking a
keyword without replacement. There is code written that uses
private to enforce its threading or security invariants.
There is code written that uses private in order to shadow
another declaration. There is code that will not compile
after migration. We need more than a vague fear of complexity
generally to throw a brick through all those windows. That
brick will introduce quite a bit of complexity itself.</p>
<blockquote type="cite" style="border-width:1px;padding-left:5px;border-left-color:rgb(0,64,128)" class="">
Concerning the one-class-per-file argument, I would suggest this
counter-argument: when working in large projects, I believe it's a
good thing if the language encourages (forces is too strong a word
for my taste) a one class per file structure, it's good
practice.</blockquote>
<div class=""><br class=""></div>
</div>
</div>
<div class="">The form of the argument is invalid. Suppose I argued:
"it’s a good thing for the language to encourage one definition per
class (no extensions), it’s good practice. So we do not need
fileprivate.” That would be very silly (although it has
already been advanced as a straw-man position elsewhere in this
thread). The argument that we do not need private because nobody
should put multiple classes in a file is equally silly. There are
reasons to do so, in fact one motivation was given in
SE-0025:</div>
<div class=""><br class="">
<blockquote type="cite" style="border-width:1px;padding-left:5px;border-left-color:rgb(0,64,128)" class="">
<div id="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="margin:0px" class="">> Putting related APIs and/or related
implementations in the same file helps ensure consistency and
reduces the time to find a particular API or
implementation. </div>
</blockquote>
</div>
<div class="">
<div style="margin:0px" class=""><br class=""></div>
</div>
</div>
<div class="">These concerns are not resolved by arguments of the form “just
don’t do that”.</div>
<div class=""><br class=""></div>
<div class="">I empathize with the Swift2 programmer who got through two
releases without a scoped access modifier and is annoyed by change.
However, removing the feature now is more change, not less,
so it makes their problem worse, not better.</div>
</div>
</div>
</div>
</div>
<br class="">
<div id="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign_1490111635269603072" class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign"></div>
<br class=""><p class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257airmail_on">On March 21, 2017
at 2:17:40 AM, David Hart (<a href="mailto:david@hartbit.com" target="_blank" class="">david@hartbit.com</a>) wrote:</p>
<blockquote type="cite" class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257clean_bq">
<div style="word-wrap:break-word" class="">
<div class="">
<div class=""><span class="">Perhaps it was a mistake, but I purposefully did not go
into too much detail in the proposal because I think this debate is
purely a question of philosophy on Swift and its language features.
I did not want to add un-necessary bloat that would have added
little rationalisation. Let me try to explain the holes in the
proposal by answering your review:</span></div>
<span class=""><br class=""></span>
<div class="">
<blockquote type="cite" class="">
<div class=""><span class="">On 21 Mar 2017, at 02:26, Drew Crawford via
swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>>
wrote:</span></div>
<span class=""><br class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257Apple-interchange-newline"></span>
<div class=""><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
<span class="">I disagree quite strongly with the proposal.</span></p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
<span class="">First, the document draws conclusions without apparent
supporting evidence, e.g.</span></p>
<blockquote style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
<div style="margin:0px" class=""><span class="">> Since the release of Swift 3,
the access level change of SE–0025 was met with dissatisfaction by
a substantial proportion of the general Swift community. Those
changes can be viewed as actively harmful, the new requirement for
syntax/API changes.</span></div>
</blockquote>
<ul style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
<li style="margin:15px 0px" class=""><span class="">What is “dissatisfaction by a
substantial proportion of the general Swift community”? How was
this measured/determined?</span></li>
</ul>
</div>
</blockquote>
<span class="">It’s not feasible to measure precisely the feeling of a whole
community. But we get a feeling for it by following the
mailing-list, by talking to colleagues, by reading twitter, etc…
And it think we all agree that the debate is highly divisive and
that a “substantial proportion” of the community was dissatisfied:
I’m not arguing that it is less or more than a majority. I’m just
saying that we’ve seen a lot of talk against the original
change.</span></div>
<div class="">
<blockquote type="cite" class="">
<div class="">
<ul style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
<li style="margin:15px 0px" class=""><span class="">What was done to control for the
population happy with SE-0025 who would e.g. not be likely to take
up pitchforks?</span></li>
</ul>
</div>
</blockquote>
<span class="">That’s why its important we have this debate
now.<br class=""></span>
<blockquote type="cite" class="">
<div class="">
<ul style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
<li style="margin:15px 0px" class=""><span class="">Who argues these changes are
“actively harmful” and where were they during SE-0025?</span></li>
</ul>
</div>
</blockquote>
<div class=""><span class="">The proposal makes the argument that the changes are
actively harmful. It’s now up to debate. By the way, even if
several people (including me) were already against this proposal
during the review, I don’t see why anybody would not have the right
to change his mind, especially after several months of production
usage and argue differently now.</span></div>
<blockquote type="cite" class="">
<div class="">
<blockquote style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
<div style="margin:0px" class=""><span class="">> subtly encourages overuse of
scoped access control and discourages the more reasonable
default</span></div>
</blockquote>
<ul style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
<li style="margin:15px 0px" class=""><span class="">Who claims that scoped access is
“overused” and what is their argument for doing so?</span></li>
<li style="margin:15px 0px" class=""><span class="">Why is “fileprivate” the “more
reasonable default”? In fact neither fileprivate
*<em class="">nor*</em><span class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257Apple-converted-space"> </span>private
are default (reasonable or not!). Internal is the default. Nor does
this proposal suggest we change that. So this seems a very strange
statement.</span></li>
</ul>
</div>
</blockquote>
By default, I did not mean the syntactic default of the language
but the access modifier users will use “by default” when trying to
restrict visibility. In most languages, that keyword is “private”
so its valid to say that newcomers to the language will “default”
to using that one. If the proposal is accepted, file-scoped private
will regain that status.<br class="">
<blockquote type="cite" class="">
<div class="">
<blockquote style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
<div style="margin:0px" class="">> But is that distinction between
private and fileprivate actively used by the larger community of
Swift developers?</div>
</blockquote><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
Yes. To cite some evidence, here are codebases I actively
maintain:</p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
<font face="Courier New" class="">| codebase
| private # | fileprivate # | ratio |</font></p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
<font face="Courier New" class="">|-----------------------------<wbr class="">---------------------------|--<wbr class="">---------|---------------|----<wbr class="">---|</font></p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
<font face="Courier New" class="">| "M" (proprietary)
| 486
| 249 | 2x
|</font></p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
<font face="Courier New" class="">| "N"(proprietary)
| 179
| 59 | 3x
|</font></p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
<font face="Courier New" class="">| NaOH<span class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257Apple-converted-space"> </span><a href="https://code.sealedabstract.com/drewcrawford/NaOH" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">https://code.sealedabstra<wbr class="">ct.com/drewcrawford/NaOH</a><span class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257Apple-converted-space"> </span>|
15 | 1
| 15x |</font></p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
<font face="Courier New" class="">| atbuild<span class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257Apple-converted-space"> </span><a href="https://github.com/AnarchyTools/atbuild" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">https://github.com/Ana<wbr class="">rchyTools/atbuild</a><span class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257Apple-converted-space"> </span>
| 54 | 5
| 11x |</font></p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
So from my chair, not only is the distinction useful, but scoped
access control (private) is overwhelmingly (2-15x) more useful than
fileprivate.</p>
</div>
</blockquote>
<div class="">My own statistics in my projects show the contrary. At best,
this shows how divisive this feature is. During the discussion of
this proposal, it was argued that making decisions based upon
project statistics would be dangerous:</div>
<div class=""><br class=""></div>
<div class="">
<ul class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257MailOutline">
<li class="">In old code, statistics could be biased by the migrator having
replaced all previous instances of private by fileprivate.</li>
<li class="">In new code, satistics could be biased by people using private
because of it being the “soft-default”, regardless of proper
semantics.</li>
</ul>
</div>
<blockquote type="cite" class="">
<div class=""><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
> And if it were used pervasively, would it be worth the
cognitive load and complexity of keeping two very similar access
levels in the language? This proposal argues that answer to both
questions is no</p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
This proposal does not make any later argument about “cognitive
load” or “complexity” I can identify. Did the proposal get
truncated?</p>
</div>
</blockquote>
Sorry if I did not state it explicitly, but I see any
feature/keyword added to the language as “additional complexity”.
And that complexity is completely worth it when the feature adds
significant expressivity. I'm just arguing that the additional
scope-based access modifier does not provide enough differentiation
to be worth that complexity.<br class="">
<blockquote type="cite" class="">
<div class=""><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
What is stated (without evidence) is that "it is extremely common
to use several extensions within a file” and that use of “private”
is annoying in that case. I now extend the above table</p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
<font face="Courier New" class="">| codebase
| private # | fileprivate # | ratio | # of extensions
(>=3 extensions in file) |</font></p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
<font face="Courier New" class="">|-----------------------------<wbr class="">---------------------------|--<wbr class="">---------|---------------|----<wbr class="">---|--------------------------<wbr class="">----------------|</font></p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
<font face="Courier New" class="">| "M" (proprietary)
| 486
| 249 | 2x |
48
|</font></p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
<font face="Courier New" class="">| "N"(proprietary)
| 179
| 59 | 3x
| 84
|</font></p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
<font face="Courier New" class="">| NaOH<span class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257Apple-converted-space"> </span><a href="https://code.sealedabstract.com/drewcrawford/NaOH" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">https://code.sealedabstra<wbr class="">ct.com/drewcrawford/NaOH</a><span class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257Apple-converted-space"> </span>|
15 | 1
| 15x | 3
|</font></p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
<font face="Courier New" class="">| atbuild<span class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257Apple-converted-space"> </span><a href="https://github.com/AnarchyTools/atbuild" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">https://github.com/Ana<wbr class="">rchyTools/atbuild</a><span class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257Apple-converted-space"> </span>
| 54 | 5
| 11x | 6
|</font></p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
in order to demonstrate in my corner of Swift this is not
“extremely common”, and is actually less popular than language
features the proposal alleges aren’t used.</p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
My point here is that<span class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257Apple-converted-space"> </span><b class="">**different
people in different corners of the community program Swift
differently and use different styles**</b>. I can definitely
empathize with folks like the author who use extensions to group
functions and are annoyed that their favorite visibility modifier
grew four extra characters. Perhaps we can come up with a
keyword that is more succint.</p>
</div>
</blockquote>
I agree that different people in different corners use different
styles. But you could use that argument to validate many features
which would make a group of users happy; but all those feature
together would just add bloat to the language. Swift has been known
to be a very opinionated language, to keep the language simple yet
expressive.<br class="">
<blockquote type="cite" class="">
<div class=""><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
However, that is no reason to take away features from working
codebases. A scoped access modifier is perhaps my favorite
feature in Swift 3. Let’s not throw stuff away because it
adds extra characters to one programming style.</p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
Finally, SE-0025 establishes clear motivation for the scoped access
modifier:</p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
> Currently, the only reliable way to hide implementation
details of a class is to put the code in a separate file and mark
it as private. This is not ideal for the following reasons:</p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
> It is not clear whether the implementation details are meant
to be completely hidden or can be shared with some related code
without the danger of misusing the APIs marked as private. If a
file already has multiple classes, it is not clear if a particular
API is meant to be hidden completely or can be shared with the
other classes.</p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
> It forces a one class per file structure, which is very
limiting. Putting related APIs and/or related implementations in
the same file helps ensure consistency and reduces the time to find
a particular API or implementation. This does not mean that the
classes in the same file need to share otherwise hidden APIs, but
there is no way to express such sharability with the current access
levels.</p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
As far as I can see, the proposal does not actually address or
acknowledge these problems at all, but cheerfully returns us to
them. It would be a mistake to deprecate this feature without
examining at all why we introduced it. And realistically we
need new solutions to those problems before removing the existing
one.</p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
Drew</p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
On March 20, 2017 at 6:54:55 PM, Douglas Gregor (<a href="mailto:dgregor@apple.com" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">dgregor@apple.com</a>) wrote:</p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
Hello Swift community,</p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
The review of SE–0159 “Fix Private Access Levels” begins now and
runs through March 27, 2017. The proposal is available here:</p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">https://github.com/apple/swift<wbr class="">-evolution/blob/master/proposa<wbr class="">ls/0159-fix-private-access-lev<wbr class="">els.md</a><span class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257Apple-converted-space"> </span>Reviews
are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at</p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a><span class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257Apple-converted-space"> </span>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:</p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
Proposal link:</p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">https://github.com/apple/swift<wbr class="">-evolution/blob/master/proposa<wbr class="">ls/0159-fix-private-access-lev<wbr class="">els.md</a><span class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257Apple-converted-space"> </span>Reply
text Other replies What goes into a review?</p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
The goal of the review process is to improve the proposal under
review through constructive criticism and, eventually, determine
the direction of Swift. When writing your review, here are some
questions you might want to answer in your review:</p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
What is your evaluation of the proposal? 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? If you
have used other languages or libraries with a similar feature, how
do you feel that this proposal compares to those? How much effort
did you put into your review? A glance, a quick reading, or an
in-depth study? More information about the Swift evolution process
is available at</p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
<a href="https://github.com/apple/swift-evolution/blob/master/process.md" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">https://github.com/apple/swift<wbr class="">-evolution/blob/master/process<wbr class="">.md</a><span class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257Apple-converted-space"> </span>Thank
you,</p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
-Doug</p><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
Review Manager</p>
<hr style="height:0.2em;border:0px;color:rgb(204,204,204);background-color:rgb(204,204,204);display:inherit;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><p style="margin:15px 0px;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
swift-evolution-announce mailing list<span class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257Apple-converted-space"> </span><a href="mailto:swift-evolution-announce@swift.org" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">swift-evolution-announce@<wbr class="">swift.org</a><span class="m_3003716928823358062gmail-m_-4816332181787402365gmail-m_-3159363955800718257Apple-converted-space"> </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution-announce" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">https://lists.swift.<wbr class="">org/mailman/listinfo/swift-evo<wbr class="">lution-announce</a></p>
<span style="font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254);float:none;display:inline" class="">______________________________<wbr class="">_________________</span><br style="font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
<span style="font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254);float:none;display:inline" class="">
swift-evolution mailing list</span><br style="font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
<a href="mailto:swift-evolution@swift.org" style="color:rgb(65,131,196);background-color:rgb(254,254,254);text-decoration:none;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank" class="">swift-evolution@swift.org</a><br style="font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="color:rgb(65,131,196);background-color:rgb(254,254,254);text-decoration:none;font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a><br style="font-family:'helvetica neue',helvetica,arial,sans-serif;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)" class="">
</div>
</blockquote>
</div>
<br class=""></div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
<br class="">
______________________________<wbr class="">_________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote>
</div>
<br class=""></div>
</div>
</div></div></span></blockquote></div></div></div></blockquote></div><br class=""></div></div>
</div></blockquote><blockquote type="cite" class=""><div class=""><span class="">______________________________<wbr class="">_________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a></span><br class=""></div></blockquote></div></div></div></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></body></html>