<div dir="ltr">This is a good example of the arguments against the proposal. Let me try to summarize and address them:<div><br></div><div>1) using a convention is sufficient to declare intent</div><div>2) the programmer changing the file should know what he is doing, so a comment should be enough</div><div>3) since the programmer has access to the code, he can just change the access level, so there is no need to go beyond the file scope</div><div>4) given the previous arguments, this small addition is not worth increasing the language complexity</div><div><br></div><div>Now, let&#39;s pretend that &quot;let&quot; is not in the language and run it through the list to see if it&#39;s worth adding:</div><div><br></div><div>1) there is a common convention of using ALL_CAPS for constants (used in C). Another common convention is to use &quot;k&quot; in front of the name. Cocoa APIs use it in many places. &quot;let&quot; not need. Check.</div><div>2) if the programmer is expected to have the proper knowledge about the file he is in, this is a must for variables / constants in the *local* scope. &quot;let&quot; not needed. Check.</div><div>3) since the programmer has access to the code, he can always just change let to var. The compiler cannot help with that. &quot;Let&quot; doesn&#39;t protect then, so it&#39;s not needed. Check.</div><div>4) This definitely increases the language and implementation complexity, and especially given (3), it would be an addition that can be easily worked around, so why bother? Check.</div><div><br></div><div>And yet, it is in the language because it backs a very important concept (immutability) and lets the compiler enforce it. Moreover, Xcode keeps track of this, and if you declare something as var and use it as a constant, it will actively suggest that you change it to &quot;let&quot;.</div><div><br></div><div>We should have &quot;scoped&quot; (or &quot;local&quot;) for exactly the same reasons. Most likely, any argument against it would apply to &quot;let&quot; in much the same way (and the arguments for it are also similar to arguments for having &quot;let&quot;). And it would be great if Xcode noticed that you use something only internally and actively suggested to make it scoped. The important concepts that &quot;scoped&quot; would back are encapsulation and information hiding. Just as immutability, encapsulation is a fundamental (and related!) concept, so I don&#39;t think that the proposal needs to sell itself through compelling examples. We all know what it&#39;s about. </div><div><br><div class="gmail_quote"><div dir="ltr">On Fri, Feb 26, 2016 at 8:39 PM Stephen Celis via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; What is your evaluation of the proposal?<br>
<br>
I don&#39;t think it makes its case well. The alternatives it lists are sufficient and, if anything, mentioning them makes their case equally well (or better).<br>
<br>
The suggestion that the current behavior &quot;forces a one class per file structure&quot; is misleading. While it may require a careful API designer to use one file to scope truly private behavior, they are free to implement other parts of this class/structure/enumeration (and others) elsewhere.<br>
<br>
The one limitation of splitting logic over many files (a limitation the proposal does not mention) is that stored properties can only be defined in the initial definition of a class/structure. I can see a separate case (and proposal) to be made for allowing stored properties to be defined in extensions as long as the class/structure definition exists in the same module. I also remember reading a lukewarm discussion here around removing this limitation.<br>
<br>
&gt; Is the problem being addressed significant enough to warrant a change to Swift?<br>
<br>
No. The problems it attempts to address can already be solved with the existing levels of access control. It also feels incongruous alongside them and would make Swift&#39;s design more confusing and complex.<br>
<br>
I believe that for those that want it, this kind of scoping could be enforced using a linter.<br>
<br>
&gt; Does this proposal fit well with the feel and direction of Swift?<br>
<br>
No. Swift has lately been removing, not adding, complexity. The bar for new language features is being set rather high, and this proposal in its current state is not convincing enough.<br>
<br>
&gt; If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br>
<br>
I don&#39;t know of any other languages that have 4 levels of access control. I have used languages that have more traditional &quot;protected&quot; and &quot;private&quot; inheritance-based access control (the latter of which is similar to that suggested in this proposal). I believe the Swift team carefully considered prior art and thoughtfully designed the current setup (as described in <a href="https://github.com/apple/swift/blob/master/docs/AccessControl.rst" rel="noreferrer" target="_blank">https://github.com/apple/swift/blob/master/docs/AccessControl.rst</a>).<br>
<br>
&gt; How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br>
<br>
I read through the proposal and have thought extensively about the existing design.<br>
<br>
--<br>
Stephen<br>
<br>
_______________________________________________<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/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div></div>