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

[Dan]

I have the same feeling. Syntax highlighting is not enough to make things clear and even with it we are sometimes confused. We read swift code on GitHub, which doesn't have highlighting. Sometimes we do so in plain text. It looks like the only way to detect iVars is to open our Swift code is to open it in Xcode. So Swift is outsourcing iVar readability to Xcode, when it should be a language feature.

Given this, some teams use underscores for their iVars which is very unfortunate. Myself, I use self whenever possible to be explicit. I'd like the language to force us to be clear.
I would also like to point out that colours are a very unsafe mechanism of communicating programmer intent.

> Message: 1
> Date: Sat, 5 Dec 2015 10:35:08 +0100
> From: David Hart <david at hartbit.com>
> To: Tyler Cloutier <cloutiertyler at aol.com>
> Cc: swift-evolution at swift.org
> Subject: Re: [swift-evolution] Proposal: Re-instate mandatory self for
> 	accessing instance properties and functions
> Message-ID: <F9CA7C02-6596-4C36-A867-3613DE3D7DB7 at hartbit.com>
> Content-Type: text/plain; charset="utf-8"
> 
> As I said previously, same for me. But even if that weren't the case; I find it difficult to defend the readability of a language's feature uniquely by an editor's syntax highlighting.
> 
> The proposal here had the same objectives (but is more elegant) to what created conventions like Hungarian notation where m_ prefixes member variables.
> 
> 
> 
> Sent from my iPhone
>> On 05 Dec 2015, at 08:49, Tyler Cloutier <cloutiertyler at aol.com> wrote:
>> 
>> I'm not sure how many Swift users this effects, but I'm colorblind and I really struggle with the local vs properties syntax coloring.
>> 
>> Tyler
>> 
>> 
>> 
>>> On Dec 4, 2015, at 3:37 PM, Kevin Ballard <kevin at sb.org> wrote:
>>> 
>>> Do you use Xcode to edit Swift? Xcode gives a color to properties/methods and doesn't color local variables/arguments. Is that not sufficient to distinguish this? In my experience the color is actually better than seeing the explicit `self.` because the color can be recognized faster than reading a word, and is visible in a high-level "squint" view of the function.
>>> 
>>> If you're using another editor, well, my best suggestion there is to look into what it would take to integrate SourceKit functionality into that editor for more intelligent coloring :)
>>> 
>>> -Kevin
>>> 
>>>> On Fri, Dec 4, 2015, at 03:29 PM, Colin Cornaby wrote:
>>>> +1
>>>> 
>>>> I've had a lot of weird things happen that I've traced to mistakes in properties having the same name as function arguments. I've hardly ever had this issue in modern Obj-C.
>>>> 
>>>> I'm a little more ok with functions not needing self as it's less likely for those to shadow something like an argument, but I guess the consistency would be nice too.
>>>> 
>>>>> On Dec 04, 2015, at 01:20 PM, David Hart <david at hartbit.com> wrote:
>>>>> 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?
>>>>> 
>>>>> Just as example, my proposition makes the following piece of code illegal:
>>>>> 
>>>>> ```
>>>>> struct FooBar {
>>>>> var foo: String = "foobar"
>>>>> 
>>>>> func bar() {
>>>>> print(foo) // compiler error
>>>>> print(self.foo) // compiler happy
>>>>> }
>>>>> 
>>>>> func bar2() {
>>>>> bar() // compiler error
>>>>> self.bar() // compiler happy
>>>>> }
>>>>> }
>>>>> ```
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> 
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution