<div dir="ltr"><div>Hi all,</div><div><br></div><div>since you mentioned:</div>> <span><span style="font-size:13px;white-space:pre-wrap">Individuals or teams that feel that explicit “</span><span style="font-size:13px;white-space:pre-wrap">self.” is beneficial for their own code bases can enforce such a coding convention via tooling with the status quo.</span></span><div><span style="white-space:pre-wrap"><br></span></div><div><span style="white-space:pre-wrap">Are there any existing tools that already do that? I was hoping for a compiler flag where one could disable implicit self to keep the code more readable in out-of-Xcode scenarios, is there one? Or does the above just mean that it's "theoretically" possible to enforce it, even though there's no existing tool for it yet?</span></div><div><span style="white-space:pre-wrap"><br></span></div><div><span style="white-space:pre-wrap">I remember this being discussed in the conversation about this proposal and I haven't seen anyone being *against* there being a compiler flag, assuming it's off by default. To push that forwards, would we have to create a new proposal or could that be taken as an action coming out of this one (considering how many people still were *for* required self, even if we were in a minority)?</span></div><div><span style="white-space:pre-wrap"><br></span></div><div><span style="white-space:pre-wrap">Grateful for any advice, thanks.</span></div><div><span style="white-space:pre-wrap">Honza Dvorsky<br></span><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 6, 2016 at 8:08 AM Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>The review of <span style="font-family:'Helvetica Neue'">SE-0009 "Require self for accessing instance members`"</span> ran from December 16–20, 2015. The proposal has been <b>rejected</b>.</div><div><br></div><div><span style="white-space:pre-wrap"> </span><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md</a></div><div><br></div><div>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><br></div><div>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><br></div><div>* 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 <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002910.html" target="_blank">his review</a> when he said, “a<span style="background-color:rgb(255,255,255)"><span 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> the <a href="https://swift.org/documentation/api-design-guidelines.html" target="_blank">Swift API Design Guidelines</a>.</div><div><br></div><div>* 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><span style="background-color:rgb(255,255,255)"><span style="white-space:pre-wrap"><br></span></span></div><div><span style="background-color:rgb(255,255,255)"><span 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”, “<a href="http://self.name" target="_blank">self.name</a>”) exacerbates the problem of visual clutter. </span></span></div><div><span style="background-color:rgb(255,255,255)"><span style="white-space:pre-wrap"><br></span></span></div><div><span style="background-color:rgb(255,255,255)"><span 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><span style="background-color:rgb(255,255,255)"><span style="white-space:pre-wrap"><br></span></span></div><div><span style="background-color:rgb(255,255,255)"><span style="white-space:pre-wrap"><span style="white-space:pre-wrap"> </span>Doug Gregor</span></span></div><div><span style="background-color:rgb(255,255,255)"><span style="white-space:pre-wrap"><span style="white-space:pre-wrap"> </span>Review Manager</span></span></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=19BJctSmzX9bPdrVyjid-2BuuzMHcwjBXXtYGgrRupMdtzwzIBVXXlp2CZm5wqlLAbqYRbmfwlh572cjImBs1sQOK3DroNpuOlvkdsVWdYgCsf-2BpAMZahxRM5cXEKlFSGDS1-2BiQ073HPXW498kX43YZFxkHGJ5m-2Bcl5wfkQlfN5mCJbp7FD66Yp2H-2B7DYIryx3o9-2FPa3P4dFpQV7G9owlr9xzWCngCiBk1UMr1zWdrcHQ-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
</div>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div></div>