<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Mar 26, 2017 at 12:57 PM, David Sweeris via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span class=""><div><br></div><div>On Mar 26, 2017, at 08:50, David James via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><blockquote type="cite">I propose instead that we revise to use Alternative #3, per Vladimir’s comment and revision.<div><div><br></div><div>Revised version:</div><div><br></div><div><b>“3. Revert <font face="Courier New">private</font> to be file-based and introduce the scope-based access level under a new name (e.g.: <font face="Courier New">scoped</font>, <font face="Courier New">local</font>, etc), provided that the scope-based access modifier is not used at the top level of the file.” </b></div><div>(addendum via Vladimir’s revised comment)</div></div></blockquote><br></span><div>Yeah, <span style="background-color:rgba(255,255,255,0)">within reason, </span>I couldn&#39;t care less how &quot;private&quot;/&quot;fileprivate&quot; are <i>spelled</i>. What I&#39;m against is removing the <i>functionality</i> of the current &quot;private&quot; without simultaneously providing a semantically equivalent replacement.</div></div></blockquote><div><br></div><div><br></div><div>Conversely, I do not particularly care whether the functionality of scope-based visibility stays or goes, but I find the spelling “fileprivate” to be an ugly wart on an otherwise beautiful language.<br></div><div><br></div><div>Before the discussion on this review, I had a slight preference for removing scope-based visibility in order to simplify the access control model. After reading through the thread I have a slight preference for keeping that functionality to enable compiler verification that invariants are only touched via dedicated channels. I do not have a strong opinion either way, and I would be fine to see scope-based visibility exist under the name “scoped”, or be removed entirely.</div><div><br></div><div>However, the “fileprivate” keyword is one of the few things I actually *dislike* about Swift. As in, when I am writing code I find it annoying and offputting to use such a lengthy and inelegant term for one of the most common access levels. I think it was a mistake to change the meaning of “private” in SE-0025, and we should change it back posthaste.</div><div><br></div><div>Nevin</div></div></div></div>