[swift-evolution] [Review] Require self for accessing instance members

Thu Dec 17 17:19:05 CST 2015

* What is your evaluation of the proposal?

+1

I'm definitely going against the trend here, but I want to reserve the
right to complain about the lack of a required self later. If I don't speak
up when I have the chance, I can't really complain later.

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

I believe it is, but it took me until now to convince myself of it.

When Swift 1 was released, I was very nervous about the bugs that implicit
self would cause. In the nearly two years since then, it has caused a
significant or difficult to diagnose bug for me for two reasons: I have
been very nervous about writing such a bug, and I've used self for property
access as much as possible. But this has caused bugs for others, so it is a
problem.

Since it is optional, I am able to avoid these kinds of bugs by using
explicit self whenever possible. But I am human, and sometimes I make
mistakes, and it would be better if the compiler caught those mistakes
early. I also think the compiler should give me the peace of mind of
knowing that my collaborators aren't making the same mistakes.

As been brought up multiple times, both of these problems go away if
explicit self is enforced with a linter. But this hides the real problem
with implicit self: readability.

Explicit self, in my view, makes the code much more readable. I know others
have mentioned that self blindness will result from this proposal, but I
just don't see it. If all the selfs were meaningless, then sure, the
language is being more verbose than necessary, and thus less readable. But
I've been reviewing a lot of code, both code I've written, and code others
have written, and I've been adding/deleting explicit selfs, and I have not
found a case where, to me personally, the explicit selfs made the code less
readable, and a few cases where they have made the code more readable.

Perhaps I just don't suffer from self blindness. It's not a problem for me.
I'm willing to admit this might be a personal experience thing, where
different people have different experiences. A couple months ago on
Twitter, I quipped,Seems to me that the implied self/explicit self war
splits along the same ideological lines as the dot syntax war." The context
here is that those who were against dot syntax argued that it created lines
of code that, in isolation, was ambiguous. Unless you knew the types
referenced, you can't tell if it's an Objective-C object accessing a
property, or a C struct accessing a field.

The counterargument to this was, of course, that it's not a good idea to
try to read code in isolation anyway. You have to read it all to understand
what it does, and in that process, you will gain the context needed to tell
whether the dot syntax is a property access or something else.

This is very true, but code is seldom read beginning to end like a book.
You usually start with the function you want to understand, and keep
digging deeper until you understand how the function works, and how it fits
into the overall structure of the code. And when reading this way, explicit
self saves you a lot of time in understanding the overall structure of the
code. You can tell unambiguously from each line whether the variable is a
property or a variable with a higher scope. Being more explicit and
expressive in the small picture makes it faster and easier to understand
the big picture that dot-syntax proponents maintained was necessary for
reading code.

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

Yes, I have used other languages with this requirement, including Python
and Objective-C, as well as languages without this behavior. As others have
mentioned, in Objective-C, you can get around the self requirement by
accessing ivars directly. Some have also pointed out that some are in the
habit of aliasing properties which are used multiple times in a function to
local variables, just to avoid the self requirement. These are both poor
practices, and something I would definitely reject a code review for.

They are also not practices I have seen very often. Again, this may be a
personal experience thing.

In these languages, it is still possible to fail to add an explicit self in
some contexts, and the language will use the local variable when you intend
to use the property. The language is not psychic, and explicit self is not
a panacea, but Swift's behavior doesn't prevent these bugs either.

Ultimately I think languages with explicit self are more readable, and it's
nice that they prevent a small class of bugs.

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

I have been keeping up with these threads over the last few days and
re-evaluating my own ideas and experiences, and trying them out with new
code samples.

I have not looked at any empirical research on this subject.

On Thu, Dec 17, 2015 at 2:38 PM, Rudolf Adamkovic via swift-evolution <
swift-evolution at swift.org> wrote:

> After careful reading through all the arguments, I'm now in the -1 camp
> too.
>
> The "visual noise" examples and reasoning about consistency with the rest
> of the language totally got me.
>
> P.S. I really liked the idea to use a dot instead of dot self but yeah,
> dot is already reserved for enums.
>
> R+
>
> Sent from my iPhone
>
> On 16 Dec 2015, at 19:55, Douglas Gregor via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Hello Swift community,
>
> The review of “Require self for accessing instance members” begins now and
> runs through Sunday, December 20th. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a change
> to Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have you used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Cheers,
> Doug Gregor
> Review Manager
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> 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/20151217/01d938d4/attachment.html>