[Review] Require self for accessing instance members

Evolution Discussion
1

* What is your evaluation of the proposal?

Against.

As self.an self.example, self.you can self.see how much self.harder it is to self.understand this self.sentence. We self.are self.not self.designed to self.scan words with self.self. in self.front of self.them.

The problem with this proposal is simply that using “self.blah” all over the place makes the code less readable. Yes, it can eliminate a certain class of programmer errors. But, for example, I could argue that we could eliminate a certain class of programmer errors if every time we typed in a variable we had to manually enter its type, so like,

foo = foo + 1

must be

foo.Int = foo.Int + 1.Int

Obviously this is a pathological example because the compiler would catch the error in this case anyhow, but my point is that extra words have a cost in terms of programmer comprehension, and sometimes the cost isn’t worth an incremental gain in safety.

Right now Swift is extremely readable and clean. Let’s keep it that way!

* Is the problem being addressed significant enough to warrant a change to Swift?

The problem is big enough but the solution isn’t good enough.

* Does this proposal fit well with the feel and direction of Swift?

It would if I agreed with the solution.

* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I’ve used Objective-C for 26 years, although obviously the “self.” style properties are (relatively) recent.

* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I’ve coded a ton in Swift and considered the arguments for. I also briefly considered this proposal myself a while ago, but decided that it was just too wordy to be worth the extra safety.

2

* What is your evaluation of the proposal?

Against.

I think cost of the proposed solution is greater than the benefit for a type of bug I have never encountered.

* Is the problem being addressed significant enough to warrant a change to Swift?

I think there are other ways to mitigate this kind of problem:

I would prefer syntax coloring to differentiate between local variables and properties. I understand this may not work for the color blind and could easily be overlooked.

A compiler warning when a local variable shadows a property could also help. The programmer would have to prefix the variable with either self or local in order to squelch the warning, i.e. self.title for the property or local.title for the local variable that shadows the property.

* Does this proposal fit well with the feel and direction of Swift?

Swift is known for helping the programmer avoid making mistakes. It is also known for being readable, concise and expressive. This proposal is conflicting in that it may help the programmer avoid making this type of mistake but at the expense of making the language more verbose.

One of the many things I like about Swift is how much more concise and readable it is when compared to other languages. I would like to keep it that way.

* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I used Objective-C for 10 years since it was developed at NeXT. I watched how Objective-C became more powerful but more verbose over the years. I can see how how some developers switching to Swift have mentioned not wanting to go back.

I have also used Java for about 15 years ever since WebObjects moved to Java. I find Java sometimes verbose and repetitive. I wished it had inferred typing. In Java, a local variable may shadow an instance variable. I do not recall ever seeing a bug that was a result of a name conflict between a local variable and an instance variable. Even though I can use this.foo in Java to reference an instance variable I don’t ever use it because I despise it. It makes the code more verbose and more difficult to digest.

I look forward to using Swift on the server side, but I want the language syntax to remain concise and expressive to prefer it over Java.

* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I’ve read the proposal and the comments in favor and against. I have also read a lot of the comments in the email thread. I also pictured how my code would change if the proposal were incorporated into the language and I did not like it.