[swift-evolution] [Review] Require self for accessing instance members
schristopher at bignerdranch.com
Thu Dec 17 09:47:03 CST 2015
* What is your evaluation of the proposal?
-1. I do not support the proposal.
* Is the problem being addressed significant enough to warrant a change
No. When Swift was first announced, the implicit self was one of the things
we argued about at the ranch. I was initially opposed. However after
working with the language for a short time, I slowly became convinced it
was not as significant an issue as I thought at first. In Objective-C it is
common to do something like:
NSString *foo = bar;
foo.baz = 1;
foo.blargh = 2;
self.foo = foo; // Don't forget to set the property using the temporary
This is another way to reduce the syntactic noise and baggage of otherwise
adding "self" on each line, and it makes the code's intention clearer.
However this has led to many (admittedly easy to find) bugs where I've
forgotten to assign the temporary local variable back to self at the end.
There's a similar pattern with a closure that can help prevent that issue -
but neither of these are necessary in Swift if your semantics don't need
In addition, I have been teaching Swift (via Big Nerd Ranch courses of
various kinds) since Swift was released. Implicit self has not led to as
much confusion as I was initially concerned with. I do think it allows some
misconceptions to linger longer, but the tradeoff is it makes the language
easier to start with - the language is less intimidating initially because
it supports common patterns such as this.
Finally I'll note that type inference is essential to Swift, and yet that
leaves a lot of information implicit as well in the plain-text code. Both
that and shadowing can cause as much confusion as implicit self. Others
have already explained the other scoping issues that are not addressed by
* Does this proposal fit well with the feel and direction of Swift?
No. Swift carefully and nicely rebalances clarity to also value brevity.
Others have explained well already how signal-to-noise is important. I
agree with those sentiments and think the best balance has been struck on
this issue by not requiring self.
Swift also seems to me a somewhat tool-centric language, for better and
worse. Many commenters have made the valid point that leaning on syntax
highlighting is not sufficient (or even possible) for many developers. Not
only is there the colorblind issue, but many of us regularly read code in
emails and other locations where tool assistance is not available. I do not
think that argument weighs strongly enough in this case, where in practice
you should usually have sufficient information in the code if you need to
determine local vs. object (though I'm sure examples can be constructed to
* 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 compared to Obj-C above. Obj-C also values readability, but with no
weight given to brevity (it almost considers verbosity a virtue at times).
As much as I enjoy the language, Swift's comparative terseness allows more
expressivity, while not taking it as far as Ruby or Perl.
* How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
I followed the discussion, and considered this issue when Swift was first
announced all the way through release. I've taught Swift to many classes,
some largely new to programming and many coming from an Obj-C background. I
have not done an in-depth study but I consider myself relatively
well-informed on this issue.
Big Nerd Ranch, LLC
schristopher at bignerdranch.com
On Wed, Dec 16, 2015 at 1:55 PM, 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:
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
> 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
> Doug Gregor
> Review Manager
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution