<div dir="ltr">> let/var does actually enforce intent. I have to actually change let to var before I can modify a value.<br><div><br></div><div>"scoped" also enforces intent. You have to actually mark something as at least "private" to be able to use it outside its scope.</div><div><br></div><div>> This proposal does not enforce intent. I do not have to change from “scoped”/“local” to “private” in > order to break encapsulation - I just add another method to the class.<br></div><div><br></div><div>Exactly the same is true about "private". You don't have to change from "private" to "internal" in order to make something accessible from another file -- you just add another method to the class.</div><div><br></div><div><span>> That is my primary complaint against scoped/local access - it is an arbitrary limitation that does not > improve my ability to express what is invariant in a class beyond private. I still have to assume any > change within a file may have abused scoped access permissions until I evaluate said change.</span></div><div><span><br></span></div><div><span>Exactly the same is true about "private" vs. "internal". In general, as long as you have access to the source code, you could move code around or introduce wrappers to work around the original definition without modifying it. By this logic, only "internal" and "public" make sense. And yet, "private" is in the language because it provides a way to express an intent related to encapsulation, and that intent is enforced by the compiler. "scoped" should be there for the same reason.</span></div><div><span><br></span></div><div><span>> My argument, however, is that scoped/local do not meaningfully improve safety or indicate intent > over a mix of private and partitioning code into files.</span></div><div><span><br></span></div><div><span>It does. It expresses the intent that a method or a property is private to the scope in which it is defined. This allows to provide the proper interface outside of the scope independently of where the scope is in the source code. This is important because interfaces are defined at the scope level, not file level. In the most concrete example, this allows hiding state (data encapsulation), but the same is true for methods in extensions.</span></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Feb 27, 2016 at 11:45 AM David Waite <<a href="mailto:david@alkaline-solutions.com">david@alkaline-solutions.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Feb 27, 2016, at 8:57 AM, Ilya Belenkiy via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
> This is a good example of the arguments against the proposal. Let me try to summarize and address them:<br>
><br>
> 1) using a convention is sufficient to declare intent<br>
> 2) the programmer changing the file should know what he is doing, so a comment should be enough<br>
> 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<br>
> 4) given the previous arguments, this small addition is not worth increasing the language complexity<br>
><br>
> Now, let's pretend that "let" is not in the language and run it through the list to see if it's worth adding:<br>
><br>
> 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.<br>
<br>
> 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.<br>
> 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.<br>
> 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.<br>
<br>
let/var does actually enforce intent. I have to actually change let to var before I can modify a value.<br>
<br>
This proposal does not enforce intent. I do not have to change from “scoped”/“local” to “private” in order to break encapsulation - I just add another method to the class.<br>
<br>
That is my primary complaint against scoped/local access - it is an arbitrary limitation that does not improve my ability to express what is invariant in a class beyond private. I still have to assume any change within a file may have abused scoped access permissions until I evaluate said change.<br>
<br>
Some of my personal opinion on this may be the volume of changes I try to evaluate as line-by-line diffs. A change from let to var or from non-optional to IUO shows up as part of such a change. Where code was lexically inserted within a file does not. Unlike var/let and optionals, I don’t believe scoped allows a reviewer to know that invariants were abused without an analysis of the file which was modified.<br>
<br>
More so, I can request and expect a certain evaluation about a developer changing a variable from being constant to non-constant, or from non-optional to optional. “Scoped”/“Local” does not require the developer to change a line of code to get different behavior - they simply change the location where their code is inserted. This is because access control only affects behavior at the call site, not the actual functionality of a variable or method.<br>
<br>
If a developer thinks their method requires access to scoped/local properties or methods, they will just add that to the body of the class. The *only* thing that makes such a change safe is understanding of the invariants of the class - and scoped/local do not affect the behavior of these invariants or a developer’s ability/need to understand them whatsoever.<br>
<br>
My understanding of your argument is that let/var are justified because they improve safety and more strongly indicate intent, and that scoped/local are justified for the same reason.<br>
<br>
My argument, however, is that scoped/local do not meaningfully improve safety or indicate intent over a mix of private and partitioning code into files. Scoped/local allows the access control model to scale to having more code be included in a single file.<br>
<br>
-DW</blockquote></div>