Features Download
From: Douglas Gregor via swift-evolution <swift-evolution-m3FHrko0VLzYtjvyW6yDsg <at> public.gmane.org>
Subject: [Rejected] SE-0009 Require self for accessing instance members
Newsgroups: gmane.comp.lang.swift.evolution
Date: Wednesday 6th January 2016 07:08:35 UTC (about 1 year ago)
The review of SE-0009 "Require self for accessing instance members`" ran
from December 16–20, 2015. The proposal has been rejected.


This proposal spawned a massive, polarized discussion with 200+ messages
involving 80+ participants. We’re thrilled at the enthusiasm and thank
all who participated. There were many, many interesting points made, along
with experience reports from various Swift code bases, ideas to help
mitigate the concerns that motivated the proposal, and so on.
Quantitatively, the overall community assessment of the proposal was
roughly 5:2 against requiring “self.”.

The core team agreed that this proposal is not the right direction for
Swift. There are a number of reasons for this decision:

* Mandatory “self.” introduces a significant amount of verbosity that
does not justify itself with added clarity. While it is true that mandatory
“self.” may prevent a class of bugs, the cost of eliminating those bugs
is fairly high in terms of visual clutter, which goes against the generally
uncluttered feel of Swift. Paul Cantrell put it well in his review <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002910.html>
when he said, “anything that is widely repeated becomes invisible.”
Swift aims to avoid such boilerplate and repetition in its design, a
principle also espoused by the Swift API Design Guidelines <https://swift.org/documentation/api-design-guidelines.html>.

* The requirement to use “self.” within potentially-escaping closures
is a useful indicator of the potential for retain cycles that we don’t
want to lose. Additionally, developers can optionally use “self.” when
they feel it improves clarity (e.g., when similar operations are being
performed on several different instances, of which “self” is one).

* The name-shadowing concerns behind the mandatory “self.” apply
equally well to anything found by unqualified name lookup, including names
found in the global scope. To call out members of types as requiring
qualification while global names do not (even when global names tend to be
far more numerous) feels inconsistent, but requiring qualification for
everything (e.g., “Swift.print”, “self.name”) exacerbates the
problem of visual clutter. 

* Individuals or teams that feel that explicit “self.” is beneficial
for their own code bases can enforce such a coding convention via tooling
with the status quo. If this proposal were accepted, those opposed to the
proposal would effectively have no recourse because the language itself
would be enforcing “self.”.

	Doug Gregor
	Review Manager
CD: 3ms