<div dir="ltr"><div><br></div><div> * What is your evaluation of the proposal?</div><div><span class="" style="white-space:pre"> </span>-1. I do not support the proposal.</div><div><span class="" style="white-space:pre"> </span></div><div> * Is the problem being addressed significant enough to warrant a change to Swift?</div><div><span class="" style="white-space:pre"> </span>No. When Swift was first announced, the implicit self was one of the things we argued about at the ranch. I was initially opposed. However after working with the language for a short time, I slowly became convinced it was not as significant an issue as I thought at first. In Objective-C it is common to do something like:</div><div><span class="" style="white-space:pre"> </span>NSString *foo = bar;</div><div><span class="" style="white-space:pre"> </span>foo.baz = 1;</div><div><span class="" style="white-space:pre"> </span>foo.blargh = 2;</div><div><span class="" style="white-space:pre"> </span></div><div><span class="" style="white-space:pre"> </span>self.foo = foo; // Don't forget to set the property using the temporary local!</div><div><span class="" style="white-space:pre"> </span></div><div><span class="" style="white-space:pre"> </span>This is another way to reduce the syntactic noise and baggage of otherwise adding "self" on each line, and it makes the code's intention clearer. However this has led to many (admittedly easy to find) bugs where I've forgotten to assign the temporary local variable back to self at the end. There's a similar pattern with a closure that can help prevent that issue - but neither of these are necessary in Swift if your semantics don't need them.</div><div><span class="" style="white-space:pre"> </span></div><div><span class="" style="white-space:pre"> </span>In addition, I have been teaching Swift (via Big Nerd Ranch courses of various kinds) since Swift was released. Implicit self has not led to as much confusion as I was initially concerned with. I do think it allows some misconceptions to linger longer, but the tradeoff is it makes the language easier to start with - the language is less intimidating initially because it supports common patterns such as this.</div><div><span class="" style="white-space:pre"> </span></div><div><span class="" style="white-space:pre"> </span>Finally I'll note that type inference is essential to Swift, and yet that leaves a lot of information implicit as well in the plain-text code. Both that and shadowing can cause as much confusion as implicit self. Others have already explained the other scoping issues that are not addressed by this proposal.</div><div><span class="" style="white-space:pre"> </span></div><div> * Does this proposal fit well with the feel and direction of Swift?</div><div><span class="" style="white-space:pre"> </span>No. Swift carefully and nicely rebalances clarity to also value brevity. Others have explained well already how signal-to-noise is important. I agree with those sentiments and think the best balance has been struck on this issue by not requiring self.</div><div><span class="" style="white-space:pre"> </span></div><div><span class="" style="white-space:pre"> </span>Swift also seems to me a somewhat tool-centric language, for better and worse. Many commenters have made the valid point that leaning on syntax highlighting is not sufficient (or even possible) for many developers. Not only is there the colorblind issue, but many of us regularly read code in emails and other locations where tool assistance is not available. I do not think that argument weighs strongly enough in this case, where in practice you should usually have sufficient information in the code if you need to determine local vs. object (though I'm sure examples can be constructed to the contrary).</div><div><span class="" style="white-space:pre"> </span></div><div><span class="" style="white-space:pre"> </span></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><span class="" style="white-space:pre"> </span>I've compared to Obj-C above. Obj-C also values readability, but with no weight given to brevity (it almost considers verbosity a virtue at times). As much as I enjoy the language, Swift's comparative terseness allows more expressivity, while not taking it as far as Ruby or Perl. </div><div><span class="" style="white-space:pre"> </span></div><div> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</div><div><span class="" style="white-space:pre"> </span>I followed the discussion, and considered this issue when Swift was first announced all the way through release. I've taught Swift to many classes, some largely new to programming and many coming from an Obj-C background. I have not done an in-depth study but I consider myself relatively well-informed on this issue.</div><div><br></div><div>Sincerely,</div><div>Step Christopher</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">Step Christopher<div>Big Nerd Ranch, LLC<br></div><div><a href="mailto:schristopher@bignerdranch.com" target="_blank">schristopher@bignerdranch.com</a></div><div><br></div></div></div></div>
<br><div class="gmail_quote">On Wed, Dec 16, 2015 at 1:55 PM, Douglas Gregor 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">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=FcqcGV1X8K7Vnxfj3w9H7RBvIFFHk0as3UHXRDc-2BSJsaYv-2BKSPAHkCw7ylKHm-2FTX8g-2FeW80Np2DG81-2B2GGkZlA8bIZLgQtBbBcuAMBkga4bNGje3cnuOupV-2Fsc6YxVuQtKELZktKiYRCa1QeNgoR2q7pdpf-2F3XQ1oZ2L6USJOh01bOo8n45qgL6gUZ4MmkZGaiXz3DAnv0ArzvMdPa51uCA8lehmD-2BSmIKkgZvP5QdQ-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>