<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=""><div class="">Please forgive the length of the treatise that follows. It touches on some strong feelings I have about code as information design.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><b class="">┝━━━ What is your evaluation of the proposal? ━━━━┥<br class=""></b></div><div class=""><br class=""></div><div class=""><div class="">I strongly oppose this proposal.</div><div class=""><br class=""></div><div class="">Despite the author’s claims, it reduces the signal/noise ratio of code, and thus has a negative impact on readability which outweighs its marginal safety benefit.</div><div class=""><br class=""></div><div class="">Developer opinion is strong, but strongly divided. Can one answer work for everyone? Consider: Teams who like this proposal have easy recourse if it is rejected: they can enable a build-time lint checker which will makes look and feel almost exactly like a language feature. However, teams who prefer implicit self have no recourse if this proposal is accepted.</div><div class=""><br class=""></div><div class="">This is, and should remain, a matter of style and taste left to individual teams.</div><div class=""><br class=""></div></div><div class=""><br class=""></div><div class=""><b class="">┝━━━</b><b class=""> Does this proposal fit well with the feel and direction of Swift? </b><b class="">━━━━┥</b></div><div class=""><br class=""></div><div class="">No, despite the proposal’s arguments to the contrary.</div><div class=""><b class=""><br class=""></b></div><div class=""><b class="">• This proposal confuses <b class="">verbosity</b> with clarity</b><b class="">.</b></div><div class=""><br class=""></div><div class="">In its support, the proposal quotes Swift API guidelines that talk about clarity at point of use taking precedence over brevity. Note, however, that those guidelines do not speak <i class="">against</i> brevity either; they merely call out obsessive code golf as a fool’s errand.</div><div class=""><br class=""></div><div class="">Clarity comes neither from brevity nor from verbosity, but from mindfulness about which information to express. Both excessive conciseness and excessive repetition injure clarity.</div><div class=""><br class=""></div><div class=""><div class="">In several places, these very same Swift guidelines that warn against brevity for its own sake also identify brevity as a way of achieving clarity. For example, in the “Omit Needless Words” section, they state, “More words may be needed to clarify intent or disambiguate meaning, but those that are redundant with information the reader already possesses should be omitted.”</div><div class=""><br class=""></div><div class="">That section proceeds to recommend that this is bad:</div><div class=""><br class=""></div><div class=""> allViews.removeElement(cancelButton)</div><div class=""><br class=""></div><div class="">… and this is clearer:</div><div class=""><br class=""></div><div class=""> allViews.remove(cancelButton)</div><div class=""><br class=""></div><div class="">…because the cancelButton argument already is of type Element.</div><div class=""><br class=""></div><div class="">Take note! The guidelines consider information redundant, and thus inadvisable, merely because it is already present <i class="">in inferred information that may not have ever been stated</i><i class=""> explicitly</i><i class=""> near the call site</i>. A “self.” that adds no further information certainly runs afoul of this principle.</div></div><div class=""><br class=""></div><div class="">This brings us to the core of my rejection:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><b class="">Anything that is widely repeated becomes invisible.</b></div><div class=""><b class=""><br class=""></b></div><div class="">This truth shoots an arrow through the heart of the preposterous argument that “explicit > implicit, always.” Imagine how ridiculous our code would look if we truly took this to heart! Instead of “let x = 1 + 1”, we'd have “allocate(constant, stack_allocated, unsynchronized, 32 bits) → name(“x”, locally_scoped); x ← integer_addition(1, 1, min: -2^31, max:2^31-1, overflow: exception)” … or wait, no, even that leaves things such as the meaning of “integer” implicit. Explicit always better? Really? Shouldn’t we then have to state the Peano Axioms every time we use an integer? Even LLVM IR leaves some things unstated.</div><div class=""><br class=""></div><div class="">Language design is all about what we choose to make implicit. Explicitness has no inherent virtue, and does not by itself justify this proposal. Explicitness is useful only when it is not redundant. Mandating “self.” creates redundancy. Leaving it to programmer discretion allows clarity in <i class="">all</i> cases — both when clarity is explicit <i class="">and</i> when clarity is concise.</div><div class=""><br class=""></div><div class=""><b class="">• Swift adds language features that reduce boilerplate; this proposal increases it.</b></div><div class=""><br class=""></div><div class="">(Yes, we’re still in the “Does this proposal fit well with the feel and direction of Swift?” section.)</div><div class=""><br class=""></div><div class="">Some languages, such as C and Java, show a preference for minimizing the number of language constructs, even if this comes at the expense of repetitive keystrokes — and repetitive reading. (Witness Java’s approach to properties, for example.)</div><div class=""><br class=""></div><div class="">Though that approach does have the advantage of keeping the language smaller, easier to learn, and more stable over time, Swift comes down firmly on the other side: it seeks to eliminate boilerplate, and is willing to add language features to accomplish this when the benefits are clear. For example: stored properties and their surrounding features (willSet, didSet, lazy, etc.), optional unwrapping conveniences (if let, ??, etc.), default struct initializers, default arguments, etc.</div><div class=""><br class=""></div><div class="">This proposal runs contrary to Swift’s dislike of boilerplate and senseless repetition.</div><div class=""><br class=""></div><div class=""><b class="">• This proposal runs contrary to Swift’s state purpose of being useful in a wide variety of programming domains.</b></div><div class=""><br class=""></div><div class=""><div class="">One of the surprising things that this C/C++/Java developer learned from Ruby is that there’s tremendous value when a language’s syntax can get out of the way to let library authors create domain-specific idioms.</div><div class=""><br class=""></div><div class="">Ruby’s primary technique for doing this is leaning on implicit self (and no-parens method calls; a different question!) to provide a scope in which, for example, code describing a domain model or a state machine or an HTTP router can use only language relevant to the task at hand. Swift as it stands is reasonably friendly to this approach.</div><div class=""><br class=""></div><div class="">Mandatory “self.” would rule out this sort of programming — or least many of the best technique for implementing it.</div><div class=""><br class=""></div><div class="">Chris L has stated that he’d like to see Swift work in a wide variety of programming contexts. This proposal runs counter to that goal.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><b class="">┝━━━</b><b class=""> Is the problem being addressed significant enough to warrant a change to Swift? </b><b class="">━━━━┥</b></div><div class=""><br class=""></div><div class="">Scope errors and name collisions are indeed a source of programmer error, and it’s worth considering ways to address them.</div><div class=""><br class=""></div><div class="">However, the <i class="">specific</i> problem this proposal addresses is very narrow. Because of Swift’s lowercase letter naming convention, its relative paucity of global variables and functions, and the relatively low use of method-local functions, 99% of the problem this proposal solves is confusing local variables with member variables. <i class="">That</i> specific error is already flagged in common cases by other compile-time sanity checks, such as nonsensical self-assignments (foo = foo), use of a local variable before its declaration, and initializers completing before all stored properties are initialized.</div></div><div class=""><br class=""></div><div class="">While these compiler checks clearly do not cover <i class="">all</i> accidental uses of a local func / var where a member was intended, they leave the remaining safety gap filled by this proposal fairly small.</div><div class=""><br class=""></div><div class="">If Swift were to address the problem of scope confusion, it should do so in a way that covers more than this narrow subset of mistakes.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><b class="">┝━━━</b><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><b class="">━━━━┥</b></div><div class=""><br class=""></div><div class="">I’ve worked in the following languages which have implicit self/this:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">Ruby*</li><li class="">Java</li><li class="">C++</li></ul></div><div class=""><br class=""></div><div class="">…and in the following languages which do not have it:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">Objective-C</li><li class="">Javascript</li><li class="">Coffeescript</li><li class="">Python</li></ul></div><div class=""><br class=""></div><div class="">(And gosh, did THINK C have it? I honestly can’t remember.)</div><div class=""><br class=""></div><div class="">My arguments above reflect my experiences with languages of both kinds.</div><div class=""><br class=""></div><div class="">* I realize that in the discussion thread, Ruby’s @ came up as an alternative to explicit self. However, @ ≠ self in Ruby; instead, it distinguishes member variables from methods — and Ruby properties implemented as methods. Wherever it is legal in Ruby to say “self.”, if there’s no name conflict, then it’s also legal to leave it out.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><b class="">┝━━━</b><b class=""> How much effort did you put into your review? A glance, a quick reading, or an in-depth study? </b><b class="">━━━━┥</b></div></div><div class=""><br class=""></div><div class="">Probably too much — or perhaps not enough into editing it down! :P</div><div class=""><br class=""></div><div class="">Cheers,</div><div class=""><br class=""></div><div class="">Paul</div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 16, 2015, at 12:55 PM, Douglas Gregor <<a href="mailto:dgregor@apple.com" class="">dgregor@apple.com</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=zCg-2FSGF9Wk188a6c55kLyEbrj7YhaXxFEHM-2F-2B0YAlzVtwon8zoiMeT-2FGSH9qUA-2FBOFOYXVn0ob6vX6nMPaC71oYixDv9As-2BAFhNLeCCuz5GnkjAXJPslcBp5ClFaMN-2B-2B23obxN9BgdSaCkCvT93kEWhNZmhTbCjt3kLoH9ZdL8BNPaIsroaDP4otXuvjPstuaKaGU-2BJeCKAs29dFJwfWWVGuNZeXh3VIvaa-2FacI9-2Bes-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-announce mailing list<br class=""><a href="mailto:swift-evolution-announce@swift.org" class="">swift-evolution-announce@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution-announce<br class=""></div></blockquote></div><br class=""></body></html>