<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><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div 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></div></div></div></blockquote>-1</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><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></div></div></div></blockquote><div>There are enhancements around this problem which are worthwhile in pursuing, but I don’t believe this verbosity is the right approach.</div><div><br class=""></div><div>Imagining a 3D point struct (possibly the worse case example):</div><div><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div>var length:Double {</div><div> get {</div><div> return self.x*self.x+self.y*self.z+self.z*self.z</div><div> }</div><div>}</div></blockquote><div><br class=""></div><div>this is significantly harder to read and maintain than the implicit self code</div><div><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class=""><div>var length:Double {</div><div> get {</div><div> return x*x+y*z+z*z</div><div> }</div><div>}</div></blockquote>There is a bug in the two functions - which version is easier to spot?</div><div><br class=""></div><div>So for the given points:</div><div><br class=""></div><div><ul style="box-sizing: border-box; padding: 0px 0px 0px 2em; margin-top: 0px; margin-bottom: 16px; background-color: rgb(255, 255, 255);" class=""><li style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; box-sizing: border-box;" class="">More readable at the point of use. </li></ul><div class="">I strongly agree this has been shown. The author may have meant to say the code is less ambiguous, but it is certainly less readable in my example and the examples the author gave.</div><div class=""><br class=""></div><ul style="box-sizing: border-box; padding: 0px 0px 0px 2em; margin-top: 0px; margin-bottom: 16px; background-color: rgb(255, 255, 255);" class=""><li style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; box-sizing: border-box;" class="">More consistent than only requiring <code style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; padding: 0.2em 0px; margin: 0px; background-color: rgba(0, 0, 0, 0.0392157); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class="">self</code> in closure contexts.</li></ul><div class="">This is true, but I actually would like to eventually propose not requiring self in closure contexts</div><ul style="box-sizing: border-box; padding: 0px 0px 0px 2em; margin-top: 0px; margin-bottom: 16px; background-color: rgb(255, 255, 255);" class=""><li style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; box-sizing: border-box;" class="">Less confusing from a learning point of view.</li></ul><div class="">I cannot speak to this, languages are taught different now, and I was self-taught until college. The specification of this when I was learning C++ in college was an advanced feature - we did not use ‘this’ in my first year. Once Java came about, initializers often require “this" because of parameters shadowing properties, which was the first time I really started using the keyword.</div><div class=""><br class=""></div><ul style="box-sizing: border-box; padding: 0px 0px 0px 2em; margin-top: 0px; margin-bottom: 16px; background-color: rgb(255, 255, 255);" class=""><li style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; box-sizing: border-box;" class="">Lets the compiler warn users (and avoids bugs) where the authors mean to use a local variable but instead are unknowingly using an instance property (and the other way round).</li></ul><div class="">I believe that warning the user that a variable which is being used is shadowed in all cases other than let x=x is a far better solution. This is admittedly still more ambiguous than requiring the user to explicitly reference the context of the variable/function, but there is an expectation of API knowledge when working *inside* of a class or subclass that remains whether you are explicit or implicit in referencing self.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><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></div></div></div></blockquote>I believe it represents a syntactical regression. </div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><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></div></div></div></blockquote>I have not. I know Python and Rust have explicit self parameters in function declarations, but even then they have implicit usage of that self parameter.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><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></div></div></div></div></blockquote>Somewhere between a quick reading and an in-depth study, as the discussion is not represented by the proposal, and the mailing list discussion got too big for me to follow 100%<br class=""></div><div><br class=""></div><div>-David Waite (DW)</div><br class=""></body></html>