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

[Ilya Belenkiy]

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.

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

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.

On Fri, Feb 26, 2016 at 8:39 PM Stephen Celis via swift-evolution <
swift-evolution at swift.org> wrote:

> > What is your evaluation of the proposal?
>
> 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).
>
> 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.
>
> 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.
>
> > Is the problem being addressed significant enough to warrant a change to
> Swift?
>
> 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.
>
> I believe that for those that want it, this kind of scoping could be
> enforced using a linter.
>
> > Does this proposal fit well with the feel and direction of Swift?
>
> 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.
>
> > If you have used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?
>
> 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
> https://github.com/apple/swift/blob/master/docs/AccessControl.rst).
>
> > How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
>
> I read through the proposal and have thought extensively about the
> existing design.
>
> --
> Stephen
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160227/9238c3a2/attachment.html>