<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"><span class="gmail-"><div id="gmail-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 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></blockquote></div> <div><br></div></span>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_-3159363955800718257bloop_sign_1490122739579070976" class="gmail-m_-3159363955800718257bloop_sign">* "Those changes can be viewed as actively harmful,”</div><div id="gmail-m_-3159363955800718257bloop_sign_1490122739579070976" class="gmail-m_-3159363955800718257bloop_sign">* "it is extremely common to use several extensions within a file.”</div><div id="gmail-m_-3159363955800718257bloop_sign_1490122739579070976" class="gmail-m_-3159363955800718257bloop_sign">* “[existing regime] encourages overuse of scoped access control”</div><div id="gmail-m_-3159363955800718257bloop_sign_1490122739579070976" class="gmail-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><span class="gmail-"><div><br></div><div><blockquote type="cite" style="border-width:1px;padding-left:5px;border-left-color:rgb(0,64,128)">> It has pointed quite a few times by core team members that comparison to languages is not a very strong arguments, </blockquote></div><div><br></div></span><div>The context here is that you presented an argument that Swift’s “private” was confusing to users of other languages:</div><span class="gmail-"><div><br></div><div><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></div><div><br></div></span><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><span class="gmail-"><div><br></div></span></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"><span class="gmail-"><div></div><div><blockquote type="cite" style="border-width:1px;padding-left:5px;border-left-color:rgb(0,64,128)">> Some people used the for(;;) loop, the ++ operator, var parameters.</blockquote></div><div><br></div></span><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">http://stackoverflow.com/questions/39027250/what-is-a-good-example-to-differentiate-between-fileprivate-and-private-in-swift</a>), on blogs (again, easily googled; as a single example: <a href="https://useyourloaf.com/blog/swift-3-access-controls/">https://useyourloaf.com/blog/swift-3-access-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;color:rgb(0,0,0)"> </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(0,0,0)"> </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"><span style="font-variant-ligatures:no-common-ligatures"></span><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(0,0,0)"> </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;color:rgb(0,0,0)"> </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(0,0,0)"> </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-h5"><div><p class="gmail-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_-3159363955800718257clean_bq"><span><div dir="auto"><div></div><div>
<div>
<div><br></div>
<div><br>
<div><br>
<br>
Sent from my iPhone</div>
On 21 Mar 2017, at 16:57, Drew Crawford <<a href="mailto:drew@sealedabstract.com" target="_blank">drew@sealedabstract.com</a>>
wrote:<br>
<br></div>
<blockquote type="cite">
<div>
<div id="gmail-m_-3159363955800718257bloop_customfont" style="font-family:helvetica,arial;font-size:13px;color:rgb(0,0,0);margin:0px">
<br></div>
<div id="gmail-m_-3159363955800718257bloop_customfont" style="font-family:helvetica,arial;font-size:13px;color:rgb(0,0,0);margin:0px">
<br>
<div id="gmail-m_-3159363955800718257bloop_sign_1490109825482707968" class="gmail-m_-3159363955800718257bloop_sign">
<div class="gmail-m_-3159363955800718257bloop_container">
<div class="gmail-m_-3159363955800718257bloop_frame">
<div id="gmail-m_-3159363955800718257bloop_customfont" style="margin:0px">
<div>
<blockquote type="cite" class="gmail-m_-3159363955800718257clean_bq">
<div style="word-wrap:break-word">
> 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.</div>
</blockquote>
</div>
<p>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.</p>
<p>“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.</p>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div>"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.</div>
<br>
<blockquote type="cite">
<div>
<div id="gmail-m_-3159363955800718257bloop_customfont" style="font-family:helvetica,arial;font-size:13px;color:rgb(0,0,0);margin:0px">
<div id="gmail-m_-3159363955800718257bloop_sign_1490109825482707968" class="gmail-m_-3159363955800718257bloop_sign">
<div class="gmail-m_-3159363955800718257bloop_container">
<div class="gmail-m_-3159363955800718257bloop_frame">
<div id="gmail-m_-3159363955800718257bloop_customfont" style="margin:0px">
<div>
<blockquote type="cite" class="gmail-m_-3159363955800718257clean_bq">
<div style="word-wrap:break-word">
> 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.</div>
</blockquote>
</div>
<p>Apologies, but I do not understand the argument:</p>
<ol>
<li>A user wants to restrict visibility (e.g. they are dissatisfied
with “internal”)</li>
<li>The user *chooses* private because of familiarity from another
language</li>
<li>The user is then surprised that their choice of private indeed
restricted the visibility, thus achieving their goal?</li>
</ol>
<div>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.</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br></div>
<div>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:</div>
<div><br></div>
<div><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></div>
<br>
<blockquote type="cite">
<div>
<div id="gmail-m_-3159363955800718257bloop_customfont" style="font-family:helvetica,arial;font-size:13px;color:rgb(0,0,0);margin:0px">
<div id="gmail-m_-3159363955800718257bloop_sign_1490109825482707968" class="gmail-m_-3159363955800718257bloop_sign">
<div class="gmail-m_-3159363955800718257bloop_container">
<div class="gmail-m_-3159363955800718257bloop_frame">
<div id="gmail-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_-3159363955800718257bloop_customfont" style="font-family:helvetica,arial;font-size:13px;color:rgb(0,0,0);margin:0px">
<div id="gmail-m_-3159363955800718257bloop_sign_1490109825482707968" class="gmail-m_-3159363955800718257bloop_sign">
<div class="gmail-m_-3159363955800718257bloop_container">
<div class="gmail-m_-3159363955800718257bloop_frame">
<div id="gmail-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_-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_-3159363955800718257bloop_customfont" style="font-family:helvetica,arial;font-size:13px;color:rgb(0,0,0);margin:0px">
<div id="gmail-m_-3159363955800718257bloop_sign_1490109825482707968" class="gmail-m_-3159363955800718257bloop_sign">
<div class="gmail-m_-3159363955800718257bloop_container">
<div class="gmail-m_-3159363955800718257bloop_frame">
<div id="gmail-m_-3159363955800718257bloop_customfont" style="margin:0px">
<div>
<div>
<div>
<blockquote type="cite" class="gmail-m_-3159363955800718257clean_bq">
<div style="word-wrap:break-word">
<ul class="gmail-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_-3159363955800718257bloop_customfont" style="font-family:helvetica,arial;font-size:13px;color:rgb(0,0,0);margin:0px">
<div id="gmail-m_-3159363955800718257bloop_sign_1490109825482707968" class="gmail-m_-3159363955800718257bloop_sign">
<div class="gmail-m_-3159363955800718257bloop_container">
<div class="gmail-m_-3159363955800718257bloop_frame">
<div id="gmail-m_-3159363955800718257bloop_customfont" style="margin:0px">
<div>
<div>
<div>
<blockquote type="cite" class="gmail-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_-3159363955800718257bloop_customfont" style="font-family:helvetica,arial;font-size:13px;color:rgb(0,0,0);margin:0px">
<div id="gmail-m_-3159363955800718257bloop_sign_1490109825482707968" class="gmail-m_-3159363955800718257bloop_sign">
<div class="gmail-m_-3159363955800718257bloop_container">
<div class="gmail-m_-3159363955800718257bloop_frame">
<div id="gmail-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_-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_-3159363955800718257bloop_sign_1490111635269603072" class="gmail-m_-3159363955800718257bloop_sign"></div>
<br>
<p class="gmail-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_-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_-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_-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_-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.<wbr>sealedabstract.com/<wbr>drewcrawford/NaOH</a><span class="gmail-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_-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/<wbr>AnarchyTools/atbuild</a><span class="gmail-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_-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_-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.<wbr>sealedabstract.com/<wbr>drewcrawford/NaOH</a><span class="gmail-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_-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/<wbr>AnarchyTools/atbuild</a><span class="gmail-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_-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/<wbr>swift-evolution/blob/master/<wbr>proposals/0159-fix-private-<wbr>access-levels.md</a><span class="gmail-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/<wbr>mailman/listinfo/swift-<wbr>evolution</a><span class="gmail-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/<wbr>swift-evolution/blob/master/<wbr>proposals/0159-fix-private-<wbr>access-levels.md</a><span class="gmail-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/<wbr>swift-evolution/blob/master/<wbr>process.md</a><span class="gmail-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_-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_-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-<wbr>evolution-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/<wbr>mailman/listinfo/swift-<wbr>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></span></blockquote></div><ul><li></li></ul><ul><li></li><ul><li></li></ul></ul></div></div></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div></div>