<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">The review of&nbsp;<span class="" style="font-family: 'Helvetica Neue';">SE-0009 "Require self for accessing instance members`"</span>&nbsp;ran from December 16–20, 2015. The proposal has been&nbsp;<b class="">rejected</b>.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;">        </span><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md</a></div><div class=""><br class=""></div><div class="">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.”.</div><div class=""><br class=""></div><div class="">The core team agreed that this proposal is not the right direction for Swift. There are a number of reasons for this decision:</div><div class=""><br class=""></div><div class="">* 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&nbsp;<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002910.html" class="">his review</a>&nbsp;when he said, “a<span class="" style="background-color: rgb(255, 255, 255);"><span class="" style="white-space: pre-wrap;">nything that is widely repeated becomes invisible.” Swift aims to avoid such boilerplate and repetition in its design, a principle also espoused by</span></span>&nbsp;the&nbsp;<a href="https://swift.org/documentation/api-design-guidelines.html" class="">Swift API Design Guidelines</a>.</div><div class=""><br class=""></div><div class="">* 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).</div><div class=""><span class="" style="background-color: rgb(255, 255, 255);"><span class="" style="white-space: pre-wrap;"><br class=""></span></span></div><div class=""><span class="" style="background-color: rgb(255, 255, 255);"><span class="" style="white-space: pre-wrap;">* 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. </span></span></div><div class=""><span class="" style="background-color: rgb(255, 255, 255);"><span class="" style="white-space: pre-wrap;"><br class=""></span></span></div><div class=""><span class="" style="background-color: rgb(255, 255, 255);"><span class="" style="white-space: pre-wrap;">* 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.”.</span></span></div><div class=""><span class="" style="background-color: rgb(255, 255, 255);"><span class="" style="white-space: pre-wrap;"><br class=""></span></span></div><div class=""><span class="" style="background-color: rgb(255, 255, 255);"><span class="" style="white-space: pre-wrap;"><span class="Apple-tab-span" style="white-space: pre;">        </span>Doug Gregor</span></span></div><div class=""><span class="" style="background-color: rgb(255, 255, 255);"><span class="" style="white-space: pre-wrap;"><span class="Apple-tab-span" style="white-space: pre;">        </span>Review Manager</span></span></div></body></html>