[swift-evolution] [swift-evolution-announce] [Review] SE-0025 Scoped Access Level

[David Waite]

> On Feb 27, 2016, at 8:57 AM, Ilya Belenkiy via swift-evolution <swift-evolution at swift.org> wrote:
> 
> This is a good example of the arguments against the proposal. Let me try to summarize and address them:
> 
> 1) using a convention is sufficient to declare intent
> 2) the programmer changing the file should know what he is doing, so a comment should be enough
> 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
> 4) given the previous arguments, this small addition is not worth increasing the language complexity
> 
> Now, let's pretend that "let" is not in the language and run it through the list to see if it's worth adding:
> 
> 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.

> 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.
> 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.
> 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.

let/var does actually enforce intent. I have to actually change let to var before I can modify a value.

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.

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.

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.

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.

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.

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.

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. 

-DW