<div dir="ltr">I agree with Nick that we should clarify the purpose of the proposals: to convince the community that the idea is worth formally reviewing (hence, the sales pitch), or to provide an overview of the idea and of the community's preliminary reaction to it on the lists (more impartial).<div><br></div><div>In terms of actual review: I am against the proposal.</div><div><br></div><div>The primary contention seems to be safety versus programmer convenience.</div><div><br></div><div>In terms of programmer convenience, having pervasive self for instance member access adds visual noise that makes reading code more tedious. To me, Swift code within a method is easier to visually parse than equivalent Objective-C code because I'm not constantly being distracted by "self.".</div><div><br></div><div>In terms of safety: to me, non-mandatory 'self' is about as dangerous as the more general variable shadowing/name masking which you can do elsewhere in the language. Programmer experience is anecdotal and of limited utility; that being said the stated issue has not been a problem for me, or for any of the Swift developers that I've worked with.</div><div><br></div><div>In the context of mandatory/optional "self.", the possibility of shadowing exists between instance members and local variables/parameters. Best practice is to keep methods short enough to be intelligible as a whole, with complex sub-tasks delegated to other methods. In this situation it should be trivial to tell if a particular name refers to an instance member or a local variable/parameter.</div><div><br></div><div>In terms of alternatives, this is something that an opt-in warning or a linter should be able to handle, for those disinclined to allow use of implicit self within their own codebases.</div><div><br></div><div>In terms of language philosophy, Swift is clearly not a "safety at any costs" language. (If it were, the language would look very different: array subscripts returning optionals, prohibition of shadowing altogether, etc.) Instead, Swift aims to balance safety with other factors, such as performance, accessibility to programmers coming from C-style languages, programmer ergonomics, etc (as seen by the pitch on the Swift web site and previous posts from the developer team). In that light, it only makes sense to degrade programmer ergonomics/code readability if the resultant increase in safety (or some other dimension) is worth it. I don't think it is.</div><div><br></div><div>Best,</div><div>Austin</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 16, 2015 at 12:49 PM, Hooman Mehr via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On Dec 16, 2015, at 10:55 AM, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div></blockquote><br></span><span class=""><blockquote type="cite"><div><div style="word-wrap:break-word"><div><div><div><span style="white-space:pre-wrap"> </span>* What is your evaluation of the proposal?<br></div></div></div></div></div></blockquote><div><br></div></span>-1</div><div><br></div><div>Not much to add to the discussion.</div><div><span class=""><br><blockquote type="cite"><div><div style="word-wrap:break-word"><div><div><div><span style="white-space:pre-wrap"> </span>* Is the problem being addressed significant enough to warrant a change to Swift?<br></div></div></div></div></div></blockquote><div><br></div></span><div>No. Although a suppressible/enforceable warning might be beneficial.</div><span class=""><br><blockquote type="cite"><div><div style="word-wrap:break-word"><div><div><div><span style="white-space:pre-wrap"> </span>* Does this proposal fit well with the feel and direction of Swift?<br></div></div></div></div></div></blockquote><div><br></div></span>I don’t think so. It enforces a lot of visual clutter <b>everywhere</b> to provide some benefit for people with certain coding/naming habits.</div><span class=""><div><br><blockquote type="cite"><div><div style="word-wrap:break-word"><div><div><div><span style="white-space:pre-wrap"> </span>* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br></div></div></div></div></div></blockquote><br></div></span>A quick reading.<div><br></div><div><br></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=7XtDdMHRjqIUi4tzSjSp2pWQIyxYdP6woIWn4vwV5gc4X-2FpRsKTveYIAoXbM2jce7QWfTCLUX8o7Yjg5f8kAM7DkZKd-2FB4FbHr5IokL3AqyAdDTx27VIjqNbpbXqcxfI1sGQ0ZY75h6udpFi86-2FD9FocNHXUjmFxnWHbYhj5nezCqWmxRF4guj-2F9ha4u2cGcDn74HmiWCWaWAsvZt-2Bk9FDLVPv11145K5nuY0BHsceI-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>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">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>
<br></blockquote></div><br></div>