<div dir="ltr"><div>> Ilya, I think this may be a presumptuous way of how well programmers code. When deadlines hit, those first two suggestions go out the window. And the fourth/last suggestion is not valid for me - changing naming conventions would be both more confusing and more work (context switching) than explicit self.</div><div><br></div><div>Well, I listed the things that help me deal with the shadowing problem; your team is still able to use a different solution that you have chosen for your project.</div><div><br></div><div>> Global state and class state should never be conflated </div><div><br></div><div>Well yes, moreover I tend to prohibit any global state at all. But moving things from a *local* to instance scope is quite a useful pattern. </div><div><br></div><div>Whatever syntactic changes are required can be inserted by hand, but the main point of this example is that I don't see why using an instance scope should be more painful than using a local scope.</div><div><br></div><div>> You can move code to and from closures at will</div><div><br></div><div>This is not something that I would call a benefit: normally, when moving things to closures, you have to make a decision on the capture rules, that is</div><div><br></div><div>func f() {</div><div> bar.doStuff()</div><div>}</div><div><br></div><div>can become either</div><div><br></div><div>async { [bar = bar] in </div><div> bar.doStuff()</div><div>}</div><div class="gmail_extra"><br></div><div class="gmail_extra">or</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">async { </div><div class="gmail_extra"> self.bar.doStuff()</div><div class="gmail_extra">}</div><div><br></div><div>I wouldn't say that the second capture semantics – capturing the whole self and using the value of bar at the time of executing it – is always what we want when we extract code to closures.</div><div><br></div><div>> This is actually the reason why my team chose unanimously to adopt explicit self as a strict code style guideline.</div><div><br></div><div>That's a very interesting data point, thanks.</div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Ilya.</div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 13, 2015 at 9:33 PM, Dennis Lysenko <span dir="ltr"><<a href="mailto:dennis.s.lysenko@gmail.com" target="_blank">dennis.s.lysenko@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><span class=""><p dir="ltr">> - only expose the minimum necessary amount of names in any scope </p>
<p dir="ltr">> - break functions into small part so that it's easy to see all the local name declarations</p>
<p dir="ltr">> - not use any globals, or at least name them in a visually different way (UppercaseCamelStyle)</p>
<p dir="ltr">> - name properties and locals in a different way (classProperty, local_var)</p>
</span><div dir="ltr"><p dir="ltr">Ilya, I think this may be a presumptuous way of how well programmers code. When deadlines hit, those first two suggestions go out the window. And the fourth/last suggestion is not valid for me - changing naming conventions would be both more confusing and more work (context switching) than explicit self.</p><p dir="ltr"><br></p>
<p dir="ltr">The other tangible benefit of explicit self is that code becomes more refactorable. You can move code to and from closures at will, and moving it to unsuitable contexts gives immediate negative feedback. This is actually the reason why my team chose unanimously to adopt explicit self as a strict code style guideline.<br>
</p><p dir="ltr"><br></p><p>-1 to the notion that it makes the transition from global state to class state less fluid. Global state and class state should never be conflated and implicit self can lead to such conflation. Global functions should be carefully rewritten to class dynamics when the transition is desired, and implicit self makes it easier to make that transition without careful consideration.</p><p><br></p><p>Overall, I give +1 to the explicit self proposal, -1 to using a special operator. Explicit self is neither hard nor particularly verbose in my experience; with syntax highlighting, it happens to be very readable. I love Ruby, but an @ operator for ivars would be very foreign and would kill the aesthetic of the language for me. Not sure where others stand on it.<br></p></div><div><div class="h5"><div dir="ltr">
<br><div class="gmail_quote"><div dir="ltr">On Sun, Dec 13, 2015, 4:16 AM ilya via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>> But implicit self is confusing in a lot of code</div><div><br></div></div><div dir="ltr"><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 dir="ltr"><div> }</div><div><br></div><div>}</div><div><br></div><div>> can (and does) lead to shadowing bugs,</div><div><br></div></div><div dir="ltr"><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><div dir="ltr"><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><div dir="ltr"><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 dir="ltr"><div>}</div><div><br></div><div>> If so, then use another marker. For instance :x or ^x or anything.</div><div><br></div></div><div dir="ltr"><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><div dir="ltr"><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><div dir="ltr"><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><div dir="ltr"><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 href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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: 0px !important; margin: 0px !important; padding: 0px !important; display: none !important;">
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">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=8CZIdLciSFC-2BO5jF-2FiP8qN7dBFsgCUZ50wdTsolcRPeFZHXhWdHINBDl-2FAylF1q5H8MUW82aJYxMEjV8HN6to7m6b5vy0QyiJuuNb2z9qHwVR4EMZ-2BxwPODxK2j1fe0oEg-2BXWNALwCck8rHL1ZNZyCkhIncswdglyCbjj5SAOjD6O3N3SQkVoz6LmcMqUi-2B-2BHvx8VvsbhiIc-2BHYUlC-2B1u37CzR6Hw5-2BW-2B3GIF1TH3PU-3D" alt="" width="1" height="1" border="0" style="min-height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important; display: none !important;">
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">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>
</blockquote></div></div></div></div></div>
</blockquote></div><br></div></div>