<div dir="ltr">On Tue, Mar 21, 2017 at 6:44 PM, Drew Crawford <span dir="ltr"><<a href="mailto:drew@sealedabstract.com" target="_blank">drew@sealedabstract.com</a>></span> wrote:<br><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"><div id="gmail-m_-4816332181787402365bloop_customfont" style="margin:0px"><span class="gmail-"><div style="color:rgb(0,0,0);font-family:helvetica,arial;font-size:13px"><blockquote type="cite" class="gmail-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"><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="color:rgb(0,0,0);font-family:helvetica,arial;font-size:13px">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><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)">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)"><div id="gmail-m_-4816332181787402365bloop_customfont" style="margin:0px"><p>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>3. Extensions are similar to categories in Objective-C.</p></div></blockquote></div><div>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><br></div><div>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><br></div><div>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><br></div><div>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><br></div><div>```</div><div>struct A {</div><div> // Stuff here constitutes the "raison d'etre" for A.</div><div>}</div><div><br></div><div>extension A : B {</div><div> // In the course of implementing `A`, I have discovered that</div><div> // `A` can fulfill the semantic guarantees of `B`, and in fact</div><div> // fulfills most of them already.</div><div> //</div><div> // So, I conform to B, as in so doing there are some practical</div><div> // advantages, such as gaining some default implementations.</div><div> //</div><div> // But, to conform, I may need to implement some methods</div><div> // not really essential for a functional `A`, but required nonetheless</div><div> // to conform to `B`.</div><div> //</div><div> // I implement them here in an extension; in so doing, I express</div><div> // the idea that I have, after implementing `A`, discovered its</div><div> // conformance to `B`, and I am here supplying the remaining</div><div> // implementations necessary for that conformance.</div><div> //</div><div> // That is, if `B` did not exist, neither would these functions here.</div><div> // But there may be some requirements of `B` that would be</div><div> // implemented in `A` whether or not `B` exists.</div><div> // Those are implemented above, in `struct A { ... }`.</div><div>}</div><div>```</div><div><br></div><div>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><br></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"><div id="gmail-m_-4816332181787402365bloop_customfont" style="margin:0px"><div>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><br></div><div>This, I suppose, is an argument for you to take up with Charles.</div><div> </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"><div id="gmail-m_-4816332181787402365bloop_customfont" style="margin:0px"><div></div><div>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="gmail-"><div><br></div><div><blockquote type="cite" style="border-width:1px;padding-left:5px;border-left-color:rgb(0,64,128)"><div id="gmail-m_-4816332181787402365bloop_customfont" style="margin:0px">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><div style="margin:0px"><br></div></div></span><div style="margin:0px">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><br></div><div>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><br></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"><div id="gmail-m_-4816332181787402365bloop_customfont" style="margin:0px"><div style="margin:0px"><span class="gmail-"><blockquote type="cite" style="border-width:1px;padding-left:5px;border-left-color:rgb(0,64,128)"><div id="gmail-m_-4816332181787402365bloop_customfont" style="margin:0px"><div style="margin:0px">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><div style="margin:0px"><div style="margin:0px"><br></div><div style="margin:0px">And before they were shipped, there were people asking for a scoped modifier.</div></div></div></div></div></div></blockquote><div><br></div><div>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> </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"><div id="gmail-m_-4816332181787402365bloop_customfont" style="margin:0px"><div style="margin:0px"><div><div style="margin:0px"><div style="margin:0px">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="gmail-"><div style="margin:0px"><br></div><div><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)"><div id="gmail-m_-4816332181787402365bloop_customfont" style="margin:0px"><div style="margin:0px"><div style="margin:0px"><div style="margin:0px">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>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><br></div><div>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><br></div><div>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><br></div><div>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></div><div><br></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"><div id="gmail-m_-4816332181787402365bloop_customfont" style="margin:0px"><div style="margin:0px"><div><div style="margin:0px"><span class="gmail-"><blockquote type="cite" style="border-width:1px;padding-left:5px;border-left-color:rgb(0,64,128)"><p>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><p>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">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><br></div><div>*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 `ExpressibleByStringInterpolation`.</div><div><br></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"><div id="gmail-m_-4816332181787402365bloop_customfont" style="margin:0px"><div style="margin:0px"><div><div style="margin:0px"><div><span class="gmail-"><blockquote type="cite" style="border-width:1px;padding-left:5px;border-left-color:rgb(0,64,128)"><p>The code above should compile and does not.</p></blockquote></span></div><div><p>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><br></div><div>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> <br></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"><div id="gmail-m_-4816332181787402365bloop_customfont" style="margin:0px"><div style="margin:0px"><div><div style="margin:0px"><div><span class="gmail-"><blockquote type="cite" style="border-width:1px;padding-left:5px;border-left-color:rgb(0,64,128)"><p>(a) even proponents of new `private` disagree on one of two key goals stated for new `private`;</p></blockquote></span></div><div><p>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>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></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"><div id="gmail-m_-4816332181787402365bloop_customfont" style="margin:0px"><div style="margin:0px"><div><div style="margin:0px"><div><p>I wish to improve them, and a scoped access modifier is one of the tools we have to do that.</p><span class="gmail-"><div><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)">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>The problems are described in SE-0025:</p><div><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)">> 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>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>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><br></div><div> </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"><div id="gmail-m_-4816332181787402365bloop_customfont" style="margin:0px"><div style="margin:0px"><div><div style="margin:0px"><div><div class="gmail-h5"><div style="margin:0px">On March 21, 2017 at 5:26:47 PM, Xiaodi Wu (<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>) wrote:</div></div></div></div></div></div></div><div><div class="gmail-h5"> <blockquote type="cite" class="gmail-m_-4816332181787402365clean_bq"><span><div><div></div><div>
<div dir="ltr">On Tue, Mar 21, 2017 at 3:59 PM, Drew Crawford via
swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br>
<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">
<div id="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="font-family:helvetica,arial;font-size:13px;color:rgb(0,0,0);margin:0px">
<blockquote type="cite" style="border-width:1px;padding-left:5px;border-left-color:rgb(0,64,128)">
<span class="gmail-m_-4816332181787402365gmail-"><span style="font-family:'helvetica neue',helvetica;font-size:14px"> The
arguments for the revert are in the proposal and in the discussions
in this thread.</span></span></blockquote>
</div>
<div><br></div>
What is in the proposal and this thread are a set of opinions,
e.g.<br>
<div><br></div>
<div>* "the access level change of SE-0025 was met with
dissatisfaction by a substantial proportion of the general Swift
community."<br>
<div id="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign_1490122739579070976" class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign">* "Those changes can be
viewed as actively harmful,”</div>
<div id="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign_1490122739579070976" class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign">* "it is extremely common
to use several extensions within a file.”</div>
<div id="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign_1490122739579070976" class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign">* “[existing regime]
encourages overuse of scoped access control”</div>
<div id="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign_1490122739579070976" class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign">* “[fileprivate is the]
more reasonable default”</div>
<div><br></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><span class="gmail-m_-4816332181787402365gmail-"><br></span></div>
<div>
<blockquote type="cite" style="border-width:1px;padding-left:5px;border-left-color:rgb(0,64,128)">
<span class="gmail-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><span class="gmail-m_-4816332181787402365gmail-"><br></span></div>
<div>The context here is that you presented an argument that
Swift’s “private” was confusing to users of other languages:</div>
<div><span class="gmail-m_-4816332181787402365gmail-"><br></span></div>
<div><span class="gmail-m_-4816332181787402365gmail-"><span style="color:rgb(10,81,161);font-family:'normal helvetica',sans-serif">>
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><br></div>
<div>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><span class="gmail-m_-4816332181787402365gmail-"><br></span></div>
</div>
</blockquote>
<div><br></div>
<div>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 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">
<div>
<blockquote type="cite" style="border-width:1px;padding-left:5px;border-left-color:rgb(0,64,128)">
<span class="gmail-m_-4816332181787402365gmail-">> Some people used the for(;;) loop, the ++
operator, var parameters.</span></blockquote>
</div>
<div><span class="gmail-m_-4816332181787402365gmail-"><br></span></div>
<div>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><br></div>
<div>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><br></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">
<div>So the circumstances of earlier removals and this one are very
different.</div>
<div><br></div>
<div>
<div>
<div>
<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)">
<div>> • either a programmer ... will use private as often as
possible</div>
<div>> • or a programmer will … use fileprivate all the
time </div>
</blockquote>
</div>
<p>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><br></div>
<div>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><br></div>
<div>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><br></div>
<div>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><br></div>
<div>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">http://stackoverflow.<wbr>com/questions/39027250/what-<wbr>is-a-good-example-to-<wbr>differentiate-between-<wbr>fileprivate-and-private-in-<wbr>swift</a>),
on blogs (again, easily googled; as a single example: <a href="https://useyourloaf.com/blog/swift-3-access-controls/" target="_blank">https://useyourloaf.<wbr>com/blog/swift-3-access-<wbr>controls/</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><br></div>
<div>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><br></div>
<div>"How do you like my new haircut?"</div>
<div>"It, um, takes some getting used to."</div>
<div><br></div>
<div>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><br></div>
<div>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><br></div>
<div>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><br></div>
<div>```</div>
<div>
<p style="margin:0px;font-size:11px;line-height:normal;font-family:menlo;color:rgb(0,0,0)">
<span style="font-variant-ligatures:no-common-ligatures;color:rgb(186,45,162)">struct</span>
<span style="font-variant-ligatures:no-common-ligatures">Foo
{</span></p>
<p style="margin:0px;font-size:11px;line-height:normal;font-family:menlo;color:rgb(186,45,162)">
<span style="font-variant-ligatures:no-common-ligatures;color:rgb(0,0,0)"> </span>
<span style="font-variant-ligatures:no-common-ligatures">private</span>
<span style="font-variant-ligatures:no-common-ligatures">var</span>
<span style="font-variant-ligatures:no-common-ligatures;color:rgb(0,0,0)">bar:</span>
<span style="font-variant-ligatures:no-common-ligatures;color:rgb(112,61,170)">Int</span>
<span style="font-variant-ligatures:no-common-ligatures;color:rgb(0,0,0)">{</span>
<span style="font-variant-ligatures:no-common-ligatures">return</span>
<span style="font-variant-ligatures:no-common-ligatures;color:rgb(39,42,216)">42</span>
<span style="font-variant-ligatures:no-common-ligatures;color:rgb(0,0,0)">}</span></p>
<p style="margin:0px;font-size:11px;line-height:normal;font-family:menlo;color:rgb(0,0,0)">
<span style="font-variant-ligatures:no-common-ligatures">}</span></p>
<p style="margin:0px;font-size:11px;line-height:normal;font-family:menlo;color:rgb(0,0,0);min-height:13px">
<br></p>
<p style="margin:0px;font-size:11px;line-height:normal;font-family:menlo;color:rgb(186,45,162)">
<span style="font-variant-ligatures:no-common-ligatures">extension</span>
<span style="font-variant-ligatures:no-common-ligatures;color:rgb(79,129,135)">Foo</span>
<span style="font-variant-ligatures:no-common-ligatures;color:rgb(0,0,0)">{</span></p>
<p style="margin:0px;font-size:11px;line-height:normal;font-family:menlo;color:rgb(186,45,162)">
<span style="font-variant-ligatures:no-common-ligatures;color:rgb(0,0,0)"> </span>
<span style="font-variant-ligatures:no-common-ligatures">private</span>
<span style="font-variant-ligatures:no-common-ligatures">var</span>
<span style="font-variant-ligatures:no-common-ligatures;color:rgb(0,0,0)">bar:</span>
<span style="font-variant-ligatures:no-common-ligatures;color:rgb(112,61,170)">Int</span>
<span style="font-variant-ligatures:no-common-ligatures;color:rgb(0,0,0)">{</span>
<span style="font-variant-ligatures:no-common-ligatures">return</span>
<span style="font-variant-ligatures:no-common-ligatures;color:rgb(39,42,216)">43</span>
<span style="font-variant-ligatures:no-common-ligatures;color:rgb(0,0,0)">}</span></p>
<p style="margin:0px;font-size:11px;line-height:normal;font-family:menlo;color:rgb(0,0,0)">
<span style="font-variant-ligatures:no-common-ligatures">}</span></p>
</div>
<div>```</div>
<div><br></div>
<div>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><br></div>
<div>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><br></div>
<div><br></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">
<div>
<div class="gmail-m_-4816332181787402365gmail-h5">
<div>
<p class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257airmail_on">On March 21, 2017
at 1:41:48 PM, David Hart (<a href="mailto:david@hartbit.com" target="_blank">david@hartbit.com</a>) wrote:</p>
<blockquote type="cite" class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257clean_bq">
<div dir="auto">
<div>
<div>
<div><span><br></span></div>
<div><span><br></span>
<div><span><br>
<br>
Sent from my iPhone</span></div>
<span>On 21 Mar 2017, at 16:57, Drew Crawford <<a href="mailto:drew@sealedabstract.com" target="_blank">drew@sealedabstract.com</a>> wrote:<br>
<br></span></div>
<blockquote type="cite">
<div>
<div id="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="font-family:helvetica,arial;font-size:13px;color:rgb(0,0,0);margin:0px">
<span><br></span></div>
<div id="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="font-family:helvetica,arial;font-size:13px;color:rgb(0,0,0);margin:0px">
<span><br></span>
<div id="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign_1490109825482707968" class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign">
<div class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_container">
<div class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_frame">
<div id="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="margin:0px">
<div>
<blockquote type="cite" class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257clean_bq">
<div style="word-wrap:break-word"><span>> 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><span>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><span>“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><span>"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><br></span>
<blockquote type="cite">
<div>
<div id="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="font-family:helvetica,arial;font-size:13px;color:rgb(0,0,0);margin:0px">
<div id="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign_1490109825482707968" class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign">
<div class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_container">
<div class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_frame">
<div id="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="margin:0px">
<div>
<blockquote type="cite" class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257clean_bq">
<div style="word-wrap:break-word"><span>> 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><span>Apologies, but I do not understand the
argument:</span></p>
<ol>
<li><span>A user wants to restrict visibility (e.g. they are
dissatisfied with “internal”)</span></li>
<li><span>The user *chooses* private because of familiarity from
another language</span></li>
<li><span>The user is then surprised that their choice of private
indeed restricted the visibility, thus achieving their
goal?</span></li>
</ol>
<div><span>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><span><br></span></div>
<div><span>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><span><br></span></div>
<div><span><span style="background-color:rgba(255,255,255,0)">«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>
<blockquote type="cite">
<div>
<div id="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="font-family:helvetica,arial;font-size:13px;color:rgb(0,0,0);margin:0px">
<div id="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign_1490109825482707968" class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign">
<div class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_container">
<div class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_frame">
<div id="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="margin:0px">
<div>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><br></div>
<div>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><br></div>
<div>The point is that keeping both private and fileprivate feels
like an un-necessary complication:</div>
<div><br></div>
<div>• 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>• 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><br></div>
<div>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>
<blockquote type="cite">
<div>
<div id="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="font-family:helvetica,arial;font-size:13px;color:rgb(0,0,0);margin:0px">
<div id="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign_1490109825482707968" class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign">
<div class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_container">
<div class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_frame">
<div id="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="margin:0px">
<div>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><br></div>
<div>
<div>
<blockquote type="cite" class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257clean_bq">
<div style="word-wrap:break-word">> My own statistics in my
projects show the contrary. At best, this shows how divisive this
feature is.</div>
</blockquote>
</div>
<p>This *may* show that, if contrary statistics were presented, but
that hasn’t occurred.</p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div>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">
<div>
<div id="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="font-family:helvetica,arial;font-size:13px;color:rgb(0,0,0);margin:0px">
<div id="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign_1490109825482707968" class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign">
<div class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_container">
<div class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_frame">
<div id="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="margin:0px">
<div>
<div>
<div>
<blockquote type="cite" class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257clean_bq">
<div style="word-wrap:break-word">
<ul class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257MailOutline">
<li>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>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>The migrator migrated to fileprivate everywhere, not private,
disagreeing with your use of fileprivate.</div>
<br>
<blockquote type="cite">
<div>
<div id="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="font-family:helvetica,arial;font-size:13px;color:rgb(0,0,0);margin:0px">
<div id="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign_1490109825482707968" class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign">
<div class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_container">
<div class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_frame">
<div id="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="margin:0px">
<div>
<div>
<div>
<blockquote type="cite" class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257clean_bq">
<div style="word-wrap:break-word">> 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>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>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">
<div>
<div id="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="font-family:helvetica,arial;font-size:13px;color:rgb(0,0,0);margin:0px">
<div id="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign_1490109825482707968" class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign">
<div class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_container">
<div class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_frame">
<div id="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="margin:0px">
<div>
<div>
<p>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)">
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><br></div>
</div>
</div>
<div>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><br>
<blockquote type="cite" style="border-width:1px;padding-left:5px;border-left-color:rgb(0,64,128)">
<div id="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_customfont" style="margin:0px">> 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>
<div style="margin:0px"><br></div>
</div>
</div>
<div>These concerns are not resolved by arguments of the form “just
don’t do that”.</div>
<div><br></div>
<div>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>
<div id="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign_1490111635269603072" class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257bloop_sign"></div>
<br>
<p class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257airmail_on">On March 21, 2017
at 2:17:40 AM, David Hart (<a href="mailto:david@hartbit.com" target="_blank">david@hartbit.com</a>) wrote:</p>
<blockquote type="cite" class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257clean_bq">
<div style="word-wrap:break-word">
<div>
<div><span>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><br></span>
<div>
<blockquote type="cite">
<div><span>On 21 Mar 2017, at 02:26, Drew Crawford via
swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>
wrote:</span></div>
<span><br class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257Apple-interchange-newline"></span>
<div>
<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)">
<span>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)">
<span>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)">
<div style="margin:0px"><span>> 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)">
<li style="margin:15px 0px"><span>What is “dissatisfaction by a
substantial proportion of the general Swift community”? How was
this measured/determined?</span></li>
</ul>
</div>
</blockquote>
<span>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>
<blockquote type="cite">
<div>
<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)">
<li style="margin:15px 0px"><span>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>That’s why its important we have this debate
now.<br></span>
<blockquote type="cite">
<div>
<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)">
<li style="margin:15px 0px"><span>Who argues these changes are
“actively harmful” and where were they during SE-0025?</span></li>
</ul>
</div>
</blockquote>
<div><span>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">
<div>
<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)">
<div style="margin:0px"><span>> 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)">
<li style="margin:15px 0px"><span>Who claims that scoped access is
“overused” and what is their argument for doing so?</span></li>
<li style="margin:15px 0px"><span>Why is “fileprivate” the “more
reasonable default”? In fact neither fileprivate
*<em>nor*</em><span class="gmail-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>
<blockquote type="cite">
<div>
<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)">
<div style="margin:0px">> 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)">
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)">
<font face="Courier New">| 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)">
<font face="Courier New">|-----------------------------<wbr>---------------------------|--<wbr>---------|---------------|----<wbr>---|</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)">
<font face="Courier New">| "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)">
<font face="Courier New">| "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)">
<font face="Courier New">| NaOH<span class="gmail-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">https://code.sealedabstra<wbr>ct.com/drewcrawford/NaOH</a><span class="gmail-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)">
<font face="Courier New">| atbuild<span class="gmail-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">https://github.com/Ana<wbr>rchyTools/atbuild</a><span class="gmail-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)">
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>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><br></div>
<div>
<ul class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257MailOutline">
<li>In old code, statistics could be biased by the migrator having
replaced all previous instances of private by fileprivate.</li>
<li>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">
<div>
<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)">
> 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)">
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>
<blockquote type="cite">
<div>
<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)">
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)">
<font face="Courier New">| 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)">
<font face="Courier New">|-----------------------------<wbr>---------------------------|--<wbr>---------|---------------|----<wbr>---|--------------------------<wbr>----------------|</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)">
<font face="Courier New">| "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)">
<font face="Courier New">| "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)">
<font face="Courier New">| NaOH<span class="gmail-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">https://code.sealedabstra<wbr>ct.com/drewcrawford/NaOH</a><span class="gmail-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)">
<font face="Courier New">| atbuild<span class="gmail-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">https://github.com/Ana<wbr>rchyTools/atbuild</a><span class="gmail-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)">
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)">
My point here is that<span class="gmail-m_-4816332181787402365gmail-m_-3159363955800718257Apple-converted-space"> </span><b>**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>
<blockquote type="cite">
<div>
<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)">
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)">
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)">
> 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)">
> 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)">
> 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)">
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)">
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)">
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">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)">
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)">
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)">
<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">https://github.com/apple/swift<wbr>-evolution/blob/master/proposa<wbr>ls/0159-fix-private-access-<wbr>levels.md</a><span class="gmail-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)">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><span class="gmail-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)">
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)">
<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">https://github.com/apple/swift<wbr>-evolution/blob/master/proposa<wbr>ls/0159-fix-private-access-<wbr>levels.md</a><span class="gmail-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)">
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)">
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)">
<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">https://github.com/apple/swift<wbr>-evolution/blob/master/process<wbr>.md</a><span class="gmail-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)">
-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)">
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">
<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)">
swift-evolution-announce mailing list<span class="gmail-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">swift-evolution-announce@<wbr>swift.org</a><span class="gmail-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">https://lists.swift.<wbr>org/mailman/listinfo/swift-evo<wbr>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">______________________________<wbr>_________________</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)">
<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">
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)">
<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">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)">
<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">https://lists.swift.org/mailma<wbr>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)">
</div>
</blockquote>
</div>
<br></div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
<br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
<br></blockquote>
</div>
<br></div>
</div>
</div></div></span></blockquote></div></div></div></blockquote></div><br></div></div>