<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="">* What is your evaluation of the proposal?</div><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><div class=""><br class=""></div><div class="">+1. I support this proposal, although I would be in favor of making it optional via a command-line switch on the compiler, as a courtesy to those who don’t agree.</div><div class=""><br class=""></div><div class="">* Is the problem being addressed significant enough to warrant a change to Swift?<br class=""></div><div class=""><br class=""></div><div class="">Yes. Implicit self has been, in my experience, an effective cloaking device for bugs, from accidental property accesses after a shadowing variable has been deleted to just plain weird things like the infamous NSView print bug, in which calling print() to log something to the console ended up actually printing the contents of the view onto paper and ink. It also makes code less readable, as it is not immediately obvious whether the entity being referenced is a property, a global, or a local variable.</div><div class=""><br class=""></div><div class="">One can, of course, enforce self. through a style guide, however, as others have noted, coders are human. I myself have caught several accidental usages of implicit self in my own code, and I imagine others have as well.</div><div class=""><br class=""></div><div class="">Reading some of the “nay” votes on this list, I started realizing that there is a performance issue here, as well. Several people have commented on the following pattern, inherited from Objective-C:</div><div class=""><br class=""></div><div class="">func doSomething() {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>let foo = self.foo</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>self.barWithFoo(foo)</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>self.bazWithFoo(foo)</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>self.quxWithFoo(foo)</div><div class="">}</div><div class=""><br class=""></div><div class="">deriding the above pattern as being a “poor practice” which is only done to get around the self requirement. My contention is that this is far from the case, and that there are good reasons for the above pattern:</div><div class=""><br class=""></div><div class="">1) Accessing a property, in a class, is more expensive than accessing a local variable. The above code would require three message sends and/or vtable accesses instead of one, if it were not assigning the property to a local variable. These unnecessary property accesses needlessly reduce the efficiency of the program.</div><div class=""><br class=""></div><div class="">2) In a multi-threaded program, it is conceivable that the value of self.foo could change in between accesses to it. If the logic of doSomething() does not take this possibility into account (or protect itself with a locking mechanism or some such), this could lead to all sorts of odd behavior.</div><div class=""><br class=""></div><div class="">The upshot is that treating property accesses as if they were local variables can encourage developers not to keep in mind the costs and dangers of property accesses.</div><div class=""><br class=""></div><div class="">* Does this proposal fit well with the feel and direction of Swift?<br class=""></div><div class=""><br class=""></div><div class="">Yes. Despite what others have written, self.foo does not come across to me as particularly verbose. Objective-C was a verbose language, but it was not because of self. It was because -methodNamesTendedToBeWrittenToLookALotLikeThisWithLotsAndLotsOfCamelCaseWords:thatWentOn:andOn:andOn:andOn:.</div><div class=""><br class=""></div><div class="">* 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></div></div></div><div class=""><br class=""></div><div class="">I’ve done Objective-C coding for quite a long time, and was never bothered by the need to use self to access properties. I *was* bothered by the fact that instance variables were implicitly referenced without self->, making them far too easy to accidentally reference. I find it telling that almost everyone eventually ended up standardizing on the underscore prefixes for ivar names, just to avoid this issue.</div><div class=""><br class=""></div><div class="">Charles</div><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 16, 2015, at 12:55 PM, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hello Swift community,<div class=""><br class=""><div class="">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 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=""><div class="">Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div><div class=""><br class=""></div><div class="">or, if you would like to keep your feedback private, directly to the review manager.</div><div class=""><br class=""></div><div class="">What goes into a review?</div><div class=""><br class="">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 class=""><br class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>* What is your evaluation of the proposal?<br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>* Is the problem being addressed significant enough to warrant a change to Swift?<br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>* Does this proposal fit well with the feel and direction of Swift?<br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </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 class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br class=""></div><br class=""></div><div class="">More information about the Swift evolution process is available at</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/process.md" class="">https://github.com/apple/swift-evolution/blob/master/process.md</a></div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>Cheers,</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>Doug Gregor</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>Review Manager</div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=kND2tqgLiolwf1-2Bhgg7fFiaPS455NT9j3CATwJCX70-2B2iq-2BH23p365ujZgjG1pfvsgINyS-2BD01NDynU5bNDGFwUpJ7opnBzZNbedWR3ed1FjJyYTed5ZVLSZQGsDLLm1KZOGPvswSjC-2Fbr6H7KrO9VkzbPWTl9aA43AasjqDNABJgDNGGAU52akHtriga7xzStpOKsY-2Bu0Uj4uwxh1IAbr-2BzwC6VT3asrejjvqO2V70-3D" alt="" width="1" height="1" border="0" style="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;" class="">
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>