[swift-evolution] Proposal: Re-instate mandatory self for accessing instance properties and functions

[Andrey Tarantsov]

Oh, one more point: in the UI code I mentioned, I often switch between a property and a variable (e.g. turning a locally-declared label into a field if I find myself needing to update it elsewhere), and it would be very irksome to have to go and update all the references.

Also, how often do you actually encounter a bug caused by confusion between properties and variables? I had maybe two property/argument collisions and one property/local var collision that I had to debug in my 1.5 years of swifting. Compared to that, writing "self." would be an everyday annoyance.

A.


> On Dec 15, 2015, at 3:54 AM, Andrey Tarantsov via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> We are fortunate because the Python mailing list debated this exact
>> issue in 2006 (albeit, in the reverse direction). I’ll quote from
>> https://www.python.org/dev/peps/pep-3099/ (“Things that will Not
>> Change in Python 3000”):
>> 
>>> Having self be explicit is a good thing . It makes the code clear by removing ambiguity about how a variable resolves. It also makes the difference between functions and methods small.
> 
> Theoretically, if we were debating this on principle, I would agree with explicit self references.
> 
> However, I talk from experience using the relevant Apple frameworks writing dozens of apps. The UI code, which is more than a half of a typical app's code, consists of lines upon lines of simple object setup and manipulation, where (1) it is absolutely clear which names are properties and which are variables; (2) in many cases, it doesn't matter anyway (like maybe that tableView is an argument and not your property, but still the same object); (3) the code is fairly verbose as it is, and adding any extra syntactic elements obscures its intention.
> 
> And, perhaps more importantly, Xcode uses a different color to highlight property names. There's no need for further textual differentiation there.
> 
> A.
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution