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

[Kevin Ballard]

Very strong -1.

The ability to elide `self` in most contexts is really nice. Especially
when combined with the fact that SourceKitService lets Xcode syntax-
colorize properties/methods nicely so the color of the identifier tells
me whether it's a method/property on self or something else. I realize
that not everybody will be using Xcode (particularly people on other
platforms), but in time we should hopefully see other editors gain
support for SourceKit to provide more intelligent handling of Swift
code as well.

Similarly, I rely on the ability to shadow things (including properties
of self) a _lot_. And it's not just me; it's very common for e.g.
initializers to use property names as the parameter names, such as:

init(x: Int, y: Int) {    self.x = x    self.y = y }

-Kevin Ballard

On Fri, Dec 4, 2015, at 02:41 PM, Stephen Celis wrote:
> 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...
>
> On Fri, Dec 4, 2015 at 5:34 PM, Rudolf Adamkovič
> <salutis at me.com> wrote:
>> To be a little more specific, here’s a real-world example:
>>
>>
1. Say there’s a method in my class that contains a local variable
   called “title”.
>>
2. After a while, I decide to remove a part of this method, including
   the “title” variable.
>>
3. Everything compiles and seems to work just fine.
>>
4. However, I forgot to remove one more line that used the
   “title” variable.
>>
5. Because we’re in a UIViewController subclass, I'm unknowingly
   modifying view controller’s title.
>>
>>
R+
>>
>>
> On 4 Dec 2015, at 22:51, Rudolf Adamkovic <salutis at me.com> wrote:
>>
>
>>
> +1
>>
>
>>
> 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.
>>
>
>>
> 2) Also when, say fine-tuning UIKit animations, I find myself wasting
>    enormous amount of time adding and removing "self".
>>
>
>>
> R+
>>
>
>>
> Sent from my iPhone
>>
>
>>
>> On 04 Dec 2015, at 22:19, 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151204/ec70e4eb/attachment.html>