[swift-evolution] Proposal: Re-instate mandatory self for accessing instance properties and functions

[Dan Loewenherz]

On Mon, Dec 14, 2015 at 3:59 PM, Andrey Tarantsov <andrey at tarantsov.com> wrote:
>
> Oh, one more point: in the UI code I mentioned, I often switch between a property and a variable (e.g. turning a locally-declared label into a field if I find myself needing to update it elsewhere), and it would be very irksome to have to go and update all the references.
>
> Also, how often do you actually encounter a bug caused by confusion between properties and variables? I had maybe two property/argument collisions and one property/local var collision that I had to debug in my 1.5 years of swifting. Compared to that, writing “self.” would be an everyday annoyance.

The difference is that one of the options puts the onus of
“correctness” on the developer, and the other puts it on the compiler.
As infallible as I might be, I prefer to think less about this sort of
thing and let the compiler do it for me. I guess I don’t see writing
“self.” as an annoyance since I’m very much used to it in Objective-C.

I think it’s a matter of habit. Personally, I think reading code and
having to decide which scope every reference refers to is a similar
cognitive annoyance (which I’ve attempted to reduce in my own
codebases by adopting the explicit style), whereas if I know “self.”
is the *only* way to reference an instance property or function, then
there’s no ambiguity and my brain can rest easy.

Re: hard to track to bugs, a somewhat contrived example follows (but
based in reality as many methods might hypothetically re-use the name
of an out-of-scope function for more specific behavior):

    func add(a: Int, b: Int) -> Int {
        return a + b
    }

    class Add {
        func add(a: Int, b: Int) -> Int {
            return a + b + 1
        }

        func aPlusB(a: Int, b: Int) → Int {
            return add(a, b: b);
        }
    }

1. Without trying this out in a playground, how many Swift users could
be expected to know—unambiguously—the output of “aPlusB(1, 1)”?
2. How can one reference a function with the same name as an instance
method in the class from which you’re referencing from? E.g., in the above
example, I believe that the “add” function is unreachable from within the class
(please correct me if I’m wrong).

> > However, I talk from experience using the relevant Apple frameworks writing dozens of apps. The UI code, which is more than a half of a typical app’s code, consists of lines upon lines of simple object setup and manipulation, where (1) it is absolutely clear which names are properties and which are variables; (2) in many cases, it doesn't matter anyway (like maybe that tableView is an argument and not your property, but still the same object); (3) the code is fairly verbose as it is, and adding any extra syntactic elements obscures its intention.

Like you, I have shipped dozens of apps. But mostly all (save for 2
which are currently in development) are written in Objective-C, which
forces an explicit self when referencing properties. Coming from that,
I’ve found the lack of it in Swift often causes me to re-read my code
more times than I should when trying to reason about what variable is
being referenced and which is not (especially in initializers).

I’ve also always been in the “always use properties over instance
variables” camp in Objective-C (e.g., self.tableView > _tableView), so
that, combined with my Python experience, no doubt colors my opinions
here. :)

> > On Dec 15, 2015, at 3:54 AM, Andrey Tarantsov via swift-evolution <swift-evolution at swift.org> wrote:
> > And, perhaps more importantly, Xcode uses a different color to highlight property names. There’s no need for further textual differentiation there.

Very true. However, Xcode is just one of many environments in which
Swift is used. While I use Xcode all the time, I don’t think a core
language decision should be guided by its syntax highlighting
implementation (i.e., the IDE should adjust to fit the language, not
the other way around).

Dan