<div dir="ltr"><div>* What is your evaluation of the proposal?</div><div><br></div><div>+1</div><div><br></div>I'm definitely going against the trend here, but I want to reserve the right to complain about the lack of a required self later. If I don't speak up when I have the chance, I can't really complain later.<div><br></div><div>* Is the problem being addressed significant enough to warrant a change to Swift?<br></div><div><br></div><div>I believe it is, but it took me until now to convince myself of it.</div><div><br></div><div>When Swift 1 was released, I was very nervous about the bugs that implicit self would cause. In the nearly two years since then, it has caused a significant or difficult to diagnose bug for me for two reasons: I have been very nervous about writing such a bug, and I've used self for property access as much as possible. But this has caused bugs for others, so it is a problem.</div><div><br></div><div>Since it is optional, I am able to avoid these kinds of bugs by using explicit self whenever possible. But I am human, and sometimes I make mistakes, and it would be better if the compiler caught those mistakes early. I also think the compiler should give me the peace of mind of knowing that my collaborators aren't making the same mistakes.</div><div><br></div><div>As been brought up multiple times, both of these problems go away if explicit self is enforced with a linter. But this hides the real problem with implicit self: readability.</div><div><br></div><div>Explicit self, in my view, makes the code much more readable. I know others have mentioned that self blindness will result from this proposal, but I just don't see it. If all the selfs were meaningless, then sure, the language is being more verbose than necessary, and thus less readable. But I've been reviewing a lot of code, both code I've written, and code others have written, and I've been adding/deleting explicit selfs, and I have not found a case where, to me personally, the explicit selfs made the code less readable, and a few cases where they have made the code more readable.</div><div><br></div><div>Perhaps I just don't suffer from self blindness. It's not a problem for me. I'm willing to admit this might be a personal experience thing, where different people have different experiences. A couple months ago on Twitter, I quipped,Seems to me that the implied self/explicit self war splits along the same ideological lines as the dot syntax war." The context here is that those who were against dot syntax argued that it created lines of code that, in isolation, was ambiguous. Unless you knew the types referenced, you can't tell if it's an Objective-C object accessing a property, or a C struct accessing a field.</div><div><br></div><div>The counterargument to this was, of course, that it's not a good idea to try to read code in isolation anyway. You have to read it all to understand what it does, and in that process, you will gain the context needed to tell whether the dot syntax is a property access or something else.</div><div><br></div><div>This is very true, but code is seldom read beginning to end like a book. You usually start with the function you want to understand, and keep digging deeper until you understand how the function works, and how it fits into the overall structure of the code. And when reading this way, explicit self saves you a lot of time in understanding the overall structure of the code. You can tell unambiguously from each line whether the variable is a property or a variable with a higher scope. Being more explicit and expressive in the small picture makes it faster and easier to understand the big picture that dot-syntax proponents maintained was necessary for reading code.</div><div><br></div><div>* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</div><div><br></div><div>Yes, I have used other languages with this requirement, including Python and Objective-C, as well as languages without this behavior. As others have mentioned, in Objective-C, you can get around the self requirement by accessing ivars directly. Some have also pointed out that some are in the habit of aliasing properties which are used multiple times in a function to local variables, just to avoid the self requirement. These are both poor practices, and something I would definitely reject a code review for.</div><div><br></div><div>They are also not practices I have seen very often. Again, this may be a personal experience thing.</div><div><br></div><div>In these languages, it is still possible to fail to add an explicit self in some contexts, and the language will use the local variable when you intend to use the property. The language is not psychic, and explicit self is not a panacea, but Swift's behavior doesn't prevent these bugs either.</div><div><br></div><div>Ultimately I think languages with explicit self are more readable, and it's nice that they prevent a small class of bugs.</div><div><br></div><div>* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</div><div><br></div><div>I have been keeping up with these threads over the last few days and re-evaluating my own ideas and experiences, and trying them out with new code samples.</div><div><br></div><div>I have not looked at any empirical research on this subject.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 17, 2015 at 2:38 PM, Rudolf Adamkovic 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 dir="auto"><div>After careful reading through all the arguments, I'm now in the -1 camp too.</div><div><br></div><div>The "visual noise" examples and reasoning about consistency with the rest of the language totally got me.</div><div><br></div><div>P.S. I really liked the idea to use a dot instead of dot self but yeah, dot is already reserved for enums.</div><div><br></div><div>R+</div><div><br></div><div>Sent from my iPhone</div><div><div class="h5"><div><br>On 16 Dec 2015, at 19:55, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div>Hello Swift community,<div><br><div>The review of “Require self for accessing instance members” begins now and runs through Sunday, December 20th. The proposal is available here:</div></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><div>Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at</div><div><br></div><div><span style="white-space:pre-wrap"> </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div><div><br></div><div>or, if you would like to keep your feedback private, directly to the review manager.</div><div><br></div><div>What goes into a review?</div><div><br>The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:<br><br><div><span style="white-space:pre-wrap"> </span>* What is your evaluation of the proposal?<br></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><span style="white-space:pre-wrap"> </span>* Does this proposal fit well with the feel and direction of Swift?<br></div><div><span style="white-space:pre-wrap"> </span>* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br></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><br></div><div>More information about the Swift evolution process is available at</div><div><br></div><div><span style="white-space:pre-wrap"> </span><a href="https://github.com/apple/swift-evolution/blob/master/process.md" target="_blank">https://github.com/apple/swift-evolution/blob/master/process.md</a></div><div><br></div><div><span style="white-space:pre-wrap"> </span>Cheers,</div><div><span style="white-space:pre-wrap"> </span>Doug Gregor</div><div><span style="white-space:pre-wrap"> </span>Review Manager</div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=j4IybsUIPYHiRcwUyRdFaT0btoE4CwQClAWElFA0dHM7n2VvRjKa1887g3m39LRJ-2Bi03MNL5uNGSjDCJ7OxbC5bd0aCKOkHHhPlyTFp17cr65Rj1mx6vOvGg3ib2w4X4ApsrsPyZxwN9F6IqYuS43mvwRlYwYwtiMRZrgPUUrsaVyM7WHcCeXao-2FewiUo0I761ztShnyfvuA5xaoz7P0Sw-3D-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></blockquote></div></div><blockquote type="cite"><div><span>_______________________________________________</span><span class=""><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></span></div></blockquote>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=HDu-2BON2WuckNVJ2U1s3AlFgVD2xwU1HZRuo94MM4tGtyPk5pc0CiymHGV-2B-2B3R7MPjp3A-2FXnkA7RjhLHiTR78-2BZcWh2OzB54CYZPU9l5IH67aLDb4FB-2BqX6Au-2BJBvxIl1oYHHvX0lXvtfaJxUprR4RlU8KlZt-2FXJazGmm1rH-2BOKAR46Ray3uBuIPp57EBeMP0FmQGCpmcQJwCPDYvsgewlxKCwTeH3gRwDqnzt2TCX2I-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>