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

[Michael Buckley]

I'm +1 on this, for the reasons already stated by others, but not as
strongly as I was a year ago. I was very worried about this with Swift 1
was first released, but since then, I haven't actually made this mistake,
possibly because I'm so paranoid about it.

However, I really wanted to chime in about whether color should be
considered a sufficient differentiator. For me, it's much more useful to
have a textual differentiator. Perhaps I'm just really bad at memorizing
which colors mean what, but when reading code, the fact that instance
variables have a different coloring does not help me to read and understand
the code. I would sternly advocate that syntax highlighting colors not be
used as the basis for the design of this or any language.

On Fri, Dec 4, 2015 at 3:51 PM, Michael Buckley <michael at buckleyisms.com>
wrote:

> I'm +1 on this, for the reasons already stated by others, but not as
> strongly as I was a year ago. I was very worried about this with Swift 1
> was first released, but since then, I haven't actually made this mistake,
> possibly because I'm so paranoid about it.
>
> However, I really wanted to chime in about whether color should be
> considered a sufficient differentiator. For me, it's much more useful to
> have a textual differentiator. Perhaps I'm just really bad at memorizing
> which colors mean what, but when reading code, the fact that instance
> variables have a different coloring does not help me to read and understand
> the code. I would sternly advocate that syntax highlighting colors not be
> used as the basis for the design of this or any language.
>
>
>
> On Fri, 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151204/ee999620/attachment.html>