<div dir="ltr">I also prefer to keep <font face="monospace, monospace">self.</font><font face="arial, helvetica, sans-serif"> optional</font>.<div><br></div><div>In the past I wrote a lot code in Java and decided that I want to consistently use "<font face="monospace, monospace">this.</font>" in my code whenever possible. Eclipse even automatically inserted it for me every time I saved the file so I usually didn't have to write it on my own. Over time I noticed that while it did slightly improve clarity in *some* cases my code started looking like it consists of plenty of <font face="monospace, monospace">this</font> keywords with some actual logic spread in between.</div><div><br></div><div>Then Swift was released and I began migrating our Objective-C app to Swift. I noticed that the common approach was to refer to <font face="monospace, monospace">self</font> implicitly whenever possible instead of writing it explicitly and I followed that approach. Now our team has built two large Swift apps which are even broken down into plenty of modules. It happened very very rarely that I had to look up whether a variable access or function call was referring to a local symbol or to one in <font face="monospace, monospace">self</font>. Most of the time it was clear by context.</div><div><br></div><div>I liked the result so much that I started writing and converting Java-code the same way and now omit <font face="monospace, monospace">this</font> whenever possible.</div><div><br></div><div>*Bottom line:*</div><div>I agree that referring to symbols in <font face="monospace, monospace">self</font> explicitly does improve clarity in a few cases. But that comes at a high cost where the whole code gets polluted by and hidden between a lot placements of the <font face="monospace, monospace">self</font> keyword. For me the benefits of omitting <font face="monospace, monospace">self</font> for decluttering outweighs the occasional benefit of improved clarity by far.</div><div><br></div><div>Also the clarity can be improved easily by the IDE in this case. The IDE can present instance symbols and global symbols visually distinct which removes any remaining ambiguity. So in good IDEs the benefit of requiring an explicit <font face="monospace, monospace">self</font> would even be practically zero.</div><div><br></div><div><br></div><div>PS: Also note that this discussion of implicitly vs. explicitly would have to also extend to various other occasions like global vs. local vs. nested type names and even type inference, where a variable's type might also be unclear occasionally unless the IDE supports you.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 13, 2015 at 11:35 AM, ilya 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"><span class=""><div style="white-space:pre-wrap">> It might seem obvious in a small piece of code like yours, but it becomes less so in a class several hundred of lines long.</div></span><div style="white-space:pre-wrap"><br>I'll be happy to take a look at the specific examples and see if perhaps self-dot access will be useful there. <br>But even if we disagree you're still able to use self-dot access in any place where you feel this to be beneficial without any changes in the language. <br></div><span class=""><div style="white-space:pre-wrap"><br></div><div style="white-space:pre-wrap"></div>> Why use a style guide when the language can enforce rules to eliminate the ambiguity?<br><br></span>Because each project's situation can be unique. For the same reason there's no need to rush to add concurrency at the language level without considering other possibilities first. <br><br>For the record I would also like it if the "globals must start with an uppercase letter" rule were enforced by the compiler (well, not in the playground, those aren't true globals). <div><br></div><div>It still looks to me that if we make compiler enforce that and the "instance names must not start with an uppercase letter" rule this eliminates the ambiguity discussed in this thread. </div><div class="HOEnZb"><div class="h5"><div><br></div><div><div class="gmail_quote"><div dir="ltr">On Sun, Dec 13, 2015 at 13:12 David Hart <<a>david@hartbit.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><blockquote type="cite"><div dir="ltr"><div><font color="#000000"><span style="background-color:rgba(255,255,255,0)">struct Vector {</span></font></div><div><font color="#000000"><span style="background-color:rgba(255,255,255,0)"> var dx: Double</span></font></div><div><font color="#000000"><span style="background-color:rgba(255,255,255,0)"> var dy: Double</span></font></div><div><font color="#000000"><span style="background-color:rgba(255,255,255,0)"> var length: Double { return sqrt(dx*dx + dy*dy) }</span></font></div><div><font color="#000000"><span style="background-color:rgba(255,255,255,0)">}</span></font></div><div><font color="#000000"><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div><font color="#000000"><span style="background-color:rgba(255,255,255,0)">vs</span></font></div><div><font color="#000000"><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div><div><font color="#000000"><span style="background-color:rgba(255,255,255,0)">struct Vector {</span></font></div><div><font color="#000000"><span style="background-color:rgba(255,255,255,0)"> var dx: Double</span></font></div><div><font color="#000000"><span style="background-color:rgba(255,255,255,0)"> var dy: Double</span></font></div><div><font color="#000000"><span style="background-color:rgba(255,255,255,0)"> var length: Double { return sqrt(@dx*@dx + @dy*@dy) }</span></font></div><div><font color="#000000"><span style="background-color:rgba(255,255,255,0)">}</span></font></div></div><div><font color="#000000"><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div><div><font color="#000000"><span style="background-color:rgba(255,255,255,0)">struct Vector {</span></font></div><div><font color="#000000"><span style="background-color:rgba(255,255,255,0)"> var dx: Double</span></font></div><div><font color="#000000"><span style="background-color:rgba(255,255,255,0)"> var dy: Double</span></font></div><div><font color="#000000"><span style="background-color:rgba(255,255,255,0)"> var length: Double { return sqrt(self.dx*self.dx + self.dy*self.dy) }</span></font></div><div><font color="#000000"><span style="background-color:rgba(255,255,255,0)">}</span></font></div></div></div></blockquote><br></div></div><div dir="auto"><div>I don't agree with you because when reading your first example, I have to make a mental gymnastic to find out if the variables are local/global variables or if they are instance properties. It might seem obvious in a small piece of code like yours, but it becomes less so in a class several hundred of lines long.</div></div><div dir="auto"><div><br>On 13 Dec 2015, at 10:48, ilya <<a>ilya.nikokoshev@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">> For me, readability has always been more important, as we spend most of our time reading than writing code.<div>Agree.</div><div><br></div><div>> but they make code editing easier at the expense of readability. <div>Disagree. This really depends on the example. E.g. which is more readable:</div></div><div><br></div><div>struct Vector {</div><div> var dx: Double</div><div> var dy: Double</div><div> var length: Double { return sqrt(dx*dx + dy*dy) }</div><div>}</div><div><br></div><div>vs</div><div><br></div><div><div>struct Vector {</div><div> var dx: Double</div><div> var dy: Double</div><div> var length: Double { return sqrt(@dx*@dx + @dy*@dy) }</div><div>}</div></div><div><br></div><div><div>struct Vector {</div><div> var dx: Double</div><div> var dy: Double</div><div> var length: Double { return sqrt(self.dx*self.dx + self.dy*self.dy) }</div><div>}</div></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 13, 2015 at 12:40 PM, David Hart <span dir="ltr"><<a>david@hartbit.com</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>Hi Ilya,</div><div><br></div><div>Why use a style guide when the language can enforce rules to eliminate the ambiguity?</div><span><div><br></div><div><blockquote type="cite"><div dir="ltr"><font color="#000000"><span style="background-color:rgba(255,255,255,0)">On the other hand, it allows a logical explanation of how you can take code from global scope and put it into an instance scope</span></font></div></blockquote></div><div><br></div></span><span><div><blockquote type="cite"><div dir="ltr"><font color="#000000"><span style="background-color:rgba(255,255,255,0)">This helps implementing patterns like "take a long function and make it into a struct with a bunch of small functions instead".</span></font></div></blockquote></div><div><br></div></span><div>Both of your previous points make sense but they make code editing easier at the expense of readability. For me, readability has always been more important, as we spend most of our time reading than writing code.</div><span><div><br></div><div><blockquote type="cite"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><font color="#000000"><span style="background-color:rgba(255,255,255,0)">That's why I suggest using .x and .f() to mark implicit self.</span></font></div></blockquote></div></div></blockquote></div><div><br></div></span><div>I agree that that would potentially add confusion to the grammar. I've always liked the @ and @@ prefixes of Ruby for accessing instance and class properties, but I agree that symbols like that would feel a bit foreign in Swift.</div><span><font color="#888888"><div><br></div><div>David</div></font></span><div><div><div><br></div><div>On 13 Dec 2015, at 10:16, ilya via swift-evolution <<a>swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div>> But implicit self is confusing in a lot of code</div><div><br></div><div>On the other hand, it allows a logical explanation of how you can take code from global scope and put it into an instance scope:</div><div><br></div><div>let greeting = "Hello"</div><div>let name = "Michael"</div><div><br></div><div>func greet() {</div><div> print("\(greeting), \(name)")</div><div>}</div><div><br></div><div>seemlessly becomes</div><div><br></div><div>class Greeter {</div><div><br></div><div> let greeting = "Hello"</div><div> let name = "Michael"</div><div><br></div><div> func greet() {</div><div> print("\(greeting), \(name)")</div><div> }</div><div><br></div><div>}</div><div><br></div><div>> can (and does) lead to shadowing bugs,</div><div><br></div><div>There are simple strategies that help to minimize the amount of shadowing, e.g. </div><div><br></div><div>- only expose the minimum necessary amount of names in any scope </div><div>- break functions into small part so that it's easy to see all the local name declarations</div><div>- not use any globals, or at least name them in a visually different way (UppercaseCamelStyle)</div><div>- name properties and locals in a different way (classProperty, local_var)</div><div><br></div><div>Even without a formal code style, if you tend to make property names longer and local names shorter, your risk of shadowing goes down.</div><div><br></div><div>> .x and .f() to mark implicit self. I realize that this may conflict with enum usage.</div><div><br></div><div>This will lead to a lot of ambiguity:</div><div><br></div><div>func f() {</div><div> let x = NSOperation()</div><div> .name = "Name" // is it <a href="http://x.name" target="_blank">x.name</a> or <a href="http://self.name" target="_blank">self.name</a>??</div><div> ...</div><div>}</div><div><br></div><div>> If so, then use another marker. For instance :x or ^x or anything.</div><div><br></div><div>This is workable, but still I think this is one of the best points of Swift – the existence of instance scope where names are simply written as-is. This helps implementing patterns like "take a long function and make it into a struct with a bunch of small functions instead".</div><div><br></div><div>> is very difficult to reason about in diffs or any other interface that isn't an IDE (especially code review)</div><div><br></div><div>This is the point where I entirely agree, good code should be easily read in any context.</div><div>Again, may I suggest you take a look into using a style guide to differentiate visually between local and instance scope?</div><div><br></div><div>Ilya</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 13, 2015 at 10:15 AM, Rob Napier via swift-evolution <span dir="ltr"><<a>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="ltr">I wanted to reopen this discussion that seems to have trailed off. Requesting the return of self was my very first ask of Swift if I remember correctly (<a href="https://devforums.apple.com/message/1013085" target="_blank">https://devforums.apple.com/message/1013085</a>). Continued work in Swift has both strengthened and modified that ask. Here are several of the examples discussed before:<div><br></div><div><div><a href="https://gist.github.com/schwa/94b11dc0a7a331f46b25" target="_blank">https://gist.github.com/schwa/94b11dc0a7a331f46b25</a></div><div><a href="https://gist.github.com/rnapier/478465d1b15e95b98b42" target="_blank">https://gist.github.com/rnapier/478465d1b15e95b98b42</a></div><div><a href="https://gist.github.com/rnapier/4213dc64206b17df6935" target="_blank">https://gist.github.com/rnapier/4213dc64206b17df6935</a></div><div><a href="https://gist.github.com/dwineman/d6c56ec0c0e2fdb761db" target="_blank">https://gist.github.com/dwineman/d6c56ec0c0e2fdb761db</a></div><div><div><br></div><div>I get that it seems tedious to type (and read) "self." and I get that "self." is currently a hint that self might be captured (but doesn't actually mean that, since you can use self. without capturing, and sometimes have to, very often in init, so really it's basically meaningless for that use).</div><div><br></div><div>That's why I suggest using .x and .f() to mark implicit self. I realize that this may conflict with enum usage. If so, then use another marker. For instance :x or ^x or anything. But implicit self is confusing in a lot of code, can (and does) lead to shadowing bugs, and is very difficult to reason about in diffs or any other interface that isn't an IDE (especially code review).</div><div><br></div><div>Thoughts, David? I agree with your basic proposal; I just want to amend it.</div><div><br></div><div>-Rob</div></div></div><div><br></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=1p9Jer2O6jVE9KWvo-2B9iUaEyN8slp4IizyiLwsfp54PB6QfGHj8FHyiXAU-2BmFfS5mBpWjgxHgjUn6uFtGMhTY5T-2BUIfoxsGQ80Lfgxke88uoXc4nBl6ZM-2FXTHfDd3Se1pAYlk9wJ2gf64FM2FWnfnPm5oEOz-2F-2Bs-2B5ramOTdQYSZyWTSJ-2B81ZnB-2Bgg8-2BSW2uCIQsXIj-2Bb49b6i4dwDm-2F0geafX9DTnN2FJbMtkHrptIM-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">
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a>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>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=nE9rxSXA5G4kxsTVkgv43hXwizS3O2z60WweqomIrdhMWaWWrjucwTpcZ2zT7z3bfnvRKZ-2FAz1CyI8UvVSgMe91KFeU2wP3Bm8wFw-2F8wM2jPI6OAopuloTJQ1xrn3iKFWJDfdDGhSpuyHjaItiXjvIZEwDOefIWzZHJyqZtOxGigl91B0LaYEzxwixMd-2B9SgaCIKb8bViOVdI2loPJ09gsx6qUAIA9z3I1fVqd7CiEA-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><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a>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></div></blockquote></div></div></div></blockquote></div><br></div>
</div></blockquote></div></blockquote></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=6ZGE61OxINd5lLe2xYh9Ku-2BXbixWNr2nvfzp2IB1sZh-2BGjl-2BQLl599tOdw78bNdcty7wUKXcHAsSpTeA-2BsRURz6tAXeWijvsyLhS-2B1SE6HDq-2B3ePACy7231u0FtvGL-2FZLBjTFXjaWq66dqw9PyLTU-2BDruuSYsCkntiC9LgzPVHZH5OF-2BPgjLulcVdM76XXhgyuq8wsqNdlZ1jjkX-2B6p1rRRb9-2Fky6L4n2MfYhVLflU0-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></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>