<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">-1 to this proposal</div><br class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><b class="">• What is your evaluation of the proposal?</b><br class=""></div><div class=""><br class=""></div><div class="">I think the proposal addresses a minor problem in the wrong way. I think it seeks to solve the issue of shadowing variables by forcing a particular coding style on programmers.</div><div class=""><br class=""></div><div class="">There is at least one error of fact in the proposal "as is intrinsically the case in Objective-C”. This is not the case with Objective-C instance variables where “self->ivar” is not mandatory.</div><div class=""><br class=""></div><div class="">I also disagree with the assertion that it is "more readable at the point of use”. I think that is entirely subjective and I and several other participants have disagreed with this assertion.</div><div class=""><br class=""></div><div class="">I agree that it is “more consistent than only requiring self in closure contexts”. However, the use of optional self in some situations and not others actually aids readability. The often cited instance is in closures to remind the programmer that self is captured.</div><div class=""><br class=""></div><div class="">It may be fractionally less confusing from a learning point of view, but I think a programmer that cannot grasp this is going to struggle with many of the more complex language features anyway. Other languages adopt the same pattern as Swift (e.g. Java, C++, Objective-C for instance variables) and learners in these languages do not seem to have problems in this respect.</div><div class=""><br class=""></div><div class="">I think this proposal will lead to anti-patterns like the following because people will want to get rid of all the “unsightly” selfs:</div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""> struct Point </font></div><div class=""><font face="Monaco" class=""> {</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>var x: Int</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>var y: Int</font></div><div class=""><font face="Monaco" class=""><br class=""></font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func doSomethingWithXAndY()</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>{</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span> var x = self.x</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span> var y = self.y</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span> // Do complicated stuff with the local variables</font></div><div class=""><font face="Monaco" class=""> }</font></div><div class=""><font face="Monaco" class=""> }</font></div><div class=""><br class=""></div><div class="">The above could be, in itself, a source of bugs e.g. changing the local x and y and forgetting to write them back to the properties.</div><div class=""> </div><div class="">Finally, the "Alternatives Considered" section does not consider any alternatives other than status quo. There is at least one alternative to resolve the issue the proposal seeks to address.</div><div class=""><br class=""></div><div class="">I’m also concerned that the “Community Responses” section includes only the positive feedback. There was quite a lot of negative feedback on the list too. Where is it?</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><b class="">• Is the problem being addressed significant enough to warrant a change to Swift?</b><br class=""></div><div class=""><br class=""></div><div class="">Yes. However, the proposed solution is wrong. I would suggest a compiler warning for when a property or global is shadowed by a local variable would be sufficient.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><b class="">• Does this proposal fit well with the feel and direction of Swift?</b><br class=""></div><div class=""><br class=""></div><div class="">No. As a rule, the drive with Swift is to remove unnecessary boilerplate. This is adding it in.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><b class="">• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</b><br class=""></div><div class=""><br class=""></div><div class="">Only Javascript, but I find it really clunky in Javascript. I have done a lot of Java and C++ programming both of which have implicit this. I have never felt the need to have explicit this in those two languages except in certain well defined situations e.g. in the constructor where the parameters shadow the instance variables.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><b class="">• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</b><br class=""></div><div class=""><br class=""></div><div class="">I have done a lot of reading of the thread on the swift-evolution list. Other than that, only the time to write this response.</div><br class=""></body></html>