<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's pretend that "let" is not in the language and run it through the list to see if it'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 "k" in front of the name. Cocoa APIs use it in many places. "let" 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. "let" 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. "Let" doesn't protect then, so it'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 "let".</div><div><br></div><div>We should have "scoped" (or "local") for exactly the same reasons. Most likely, any argument against it would apply to "let" in much the same way (and the arguments for it are also similar to arguments for having "let"). 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 "scoped" would back are encapsulation and information hiding. Just as immutability, encapsulation is a fundamental (and related!) concept, so I don't think that the proposal needs to sell itself through compelling examples. We all know what it'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 <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> What is your evaluation of the proposal?<br>
<br>
I don'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 "forces a one class per file structure" 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>
> 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'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>
> 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>
> 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't know of any other languages that have 4 levels of access control. I have used languages that have more traditional "protected" and "private" 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>
> 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>