<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="">Stephen, as previously stated by Rudolf, his real-world example would not trigger such a warning because the title local variable no longer exists and therefore no longer shadows the instance property.<div class=""><br class=""><div class=""><div class="">To continue the discussion, here is a more detailed but rough proposal closer to the required template to advance discussions. I hope you don’t mind Rudolf, but I used your example to illustrate the proposal:</div><div class=""><br class=""></div><div class=""><b class="">Introduction</b><br class=""><br class="">Swift used to force using ‘.self’ when accessing instance properties and functions, but since dropped this requirement, only to keep it for closure captures. It now feels inconsistent, and we have lost the automatic documentation of instance properties vs local variables and instance functions vs local functions or closures. This proposal offers to re-instate the original behaviour.</div><div class=""><br class=""><b class="">Motivation</b><br class=""><br class="">The previous behaviour which this proposal hopes to re-instate provided several advantages:</div><div class=""><br class=""></div><div class="">* When reading code, it makes it obvious which are instance properties and which are local variables, as well as which are instance functions and which are local functions/closures. Moreover, a sloppy programmer can make it hard to read his code if he does not constantly use self. or not.</div><div class="">* Avoids bugs where the author meant to use one a local variable but instead is unknowingly using an instance property (and the other way round).</div><div class=""><br class=""></div><div class="">One example of a bug avoided by the original proposal (provided by Rudolf Adamkovic):</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">class MyViewController : UIViewController {</font></div><div class=""><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>@IBOutlet var button: UIButton!</font></div><div class=""><font face="Menlo" class=""> var name: String = “David"</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>func updateButton() {</font></div><div class=""><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span><span class="Apple-tab-span" style="white-space: pre;"> </span>// var title = “Hello \(name)”</font></div><div class=""><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>button.setTitle(title, forState: .Normal) // forgot to comment this line but the compiler does not complain and title is now referencing UIViewController’s title by mistake</font></div><div class=""><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>button.setTitleColor(UIColor.blackColor(), forState: .Normal)</font></div><div class=""><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>}</font></div><div class=""><font face="Menlo" class="">}</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class="">The <a href="https://swift.org/documentation/api-design-guidelines.html" class="">API Design Guidelines</a> are meant for writing APIs but I still think they represent fundamentals of Swift. The two first points are:</div><div class=""><br class=""></div><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>• Clarity at the point of use is your most important goal. Code is read far more than it is written.<br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>• Clarity is more important than brevity. Although Swift code can be compact, it is a non-goal to enable the smallest possible code with the fewest characters. Brevity in Swift code, where it occurs, is a side-effect of the strong type system and features that naturally reduce boilerplate.</div><div class=""><br class=""></div><div class="">And I believe that the proposition is directly in line with those objectives.</div><br class=""><b class="">Proposed solution</b><br class=""><br class="">Re-instante the previous behaviour where ‘self.’ was required to access instance properties and functions.<br class=""><br class=""><b class="">Detailed design</b><br class=""><br class="">It would not require changes to the grammar, and I think (not a compiler engineer) that it would require minimal amount of work.<br class=""><br class=""><b class="">Impact on existing code</b><br class=""><br class="">A lot of code written since the original change would be impacted by this proposal, but it seems like it can be easily fixed by both the migrator tool and Auto Fixes.<br class=""><br class=""><b class="">Alternatives considered</b><br class=""><br class="">The alternative is to keep the current behaviour, but it has the aforementioned disadvantages</div><br class=""><div><blockquote type="cite" class=""><div class="">On 04 Dec 2015, at 22:51, Rudolf Adamkovic <<a href="mailto:salutis@me.com" class="">salutis@me.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">+1<br class=""><br class="">1) I actually encountered at least two bugs in my app introduced by this implicit "self" behavior. It can be dangerous and hard to track down.<br class=""><br class="">2) Also when, say fine-tuning UIKit animations, I find myself wasting enormous amount of time adding and removing "self".<br class=""><br class="">R+<br class=""><br class="">Sent from my iPhone<br class=""><br class=""><blockquote type="cite" class="">On 04 Dec 2015, at 22:19, David Hart <<a href="mailto:david@hartbit.com" class="">david@hartbit.com</a>> wrote:<br class=""><br class="">I don't understand the reasoning behind removing the need to access instance properties and functions using self. Swift has always seemed to prefer readability to brevity and the feature makes the distinction between local and instance variables/functions crystal clear. Any good reason I shouldn't go on with the proposition?<br class=""><br class="">Just as example, my proposition makes the following piece of code illegal:<br class=""><br class="">```<br class="">struct FooBar {<br class=""> var foo: String = "foobar"<br class=""><br class=""> func bar() {<br class=""> print(foo) // compiler error<br class=""> print(self.foo) // compiler happy<br class=""> }<br class=""><br class=""> func bar2() {<br class=""> bar() // compiler error<br class=""> self.bar() // compiler happy<br class=""> }<br class="">}<br class="">```<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></blockquote></div></blockquote><div class=""><div class=""><blockquote type="cite" class=""><br class=""></blockquote></div></div></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 04 Dec 2015, at 23:41, Stephen Celis <<a href="mailto:stephen.celis@gmail.com" class="">stephen.celis@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Are there warnings/diagnostics that could call out when local variables shadow properties? I generally like that `self` is optional and prefer limiting its use to explicitly call out potential retain cycles. Xcode also makes it easy to introspect variable scope, though Xcode is less of a requirement these days...</div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Dec 4, 2015 at 5:34 PM, Rudolf Adamkovič <span dir="ltr" class=""><<a href="mailto:salutis@me.com" target="_blank" class="">salutis@me.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">To be a little more specific, here’s a real-world example:<br class="">
<br class="">
1. Say there’s a method in my class that contains a local variable called “title”.<br class="">
2. After a while, I decide to remove a part of this method, including the “title” variable.<br class="">
3. Everything compiles and seems to work just fine.<br class="">
4. However, I forgot to remove one more line that used the “title” variable.<br class="">
5. Because we’re in a UIViewController subclass, I'm unknowingly modifying view controller’s title.<br class="">
<span class="HOEnZb"><font color="#888888" class=""><br class="">
R+<br class="">
</font></span><div class="HOEnZb"><div class="h5"><br class="">
> On 4 Dec 2015, at 22:51, Rudolf Adamkovic <<a href="mailto:salutis@me.com" class="">salutis@me.com</a>> wrote:<br class="">
><br class="">
> +1<br class="">
><br class="">
> 1) I actually encountered at least two bugs in my app introduced by this implicit "self" behavior. It can be dangerous and hard to track down.<br class="">
><br class="">
> 2) Also when, say fine-tuning UIKit animations, I find myself wasting enormous amount of time adding and removing "self".<br class="">
><br class="">
> R+<br class="">
><br class="">
> Sent from my iPhone<br class="">
><br class="">
>> On 04 Dec 2015, at 22:19, David Hart <<a href="mailto:david@hartbit.com" class="">david@hartbit.com</a>> wrote:<br class="">
>><br class="">
>> I don't understand the reasoning behind removing the need to access instance properties and functions using self. Swift has always seemed to prefer readability to brevity and the feature makes the distinction between local and instance variables/functions crystal clear. Any good reason I shouldn't go on with the proposition?<br class="">
>><br class="">
>> Just as example, my proposition makes the following piece of code illegal:<br class="">
>><br class="">
>> ```<br class="">
>> struct FooBar {<br class="">
>> var foo: String = "foobar"<br class="">
>><br class="">
>> func bar() {<br class="">
>> print(foo) // compiler error<br class="">
>> print(self.foo) // compiler happy<br class="">
>> }<br class="">
>><br class="">
>> func bar2() {<br class="">
>> bar() // compiler error<br class="">
>> self.bar() // compiler happy<br class="">
>> }<br class="">
>> }<br class="">
>> ```<br class="">
>> _______________________________________________<br class="">
>> swift-evolution mailing list<br class="">
>> <a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
> _______________________________________________<br class="">
> swift-evolution mailing list<br class="">
> <a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></div></div></body></html>