Proposal: Re-instate mandatory self for accessing instance properties and functions


(Colin Cornaby) #1

+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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Lily Ballard) #2

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 :slight_smile:

-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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_________________________________________________
swift-evolution mailing list swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Michael Buckley) #3

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@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@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 :slight_smile:

-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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

*_______________________________________________*
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Jon Shier) #4

Relying on syntax highlighting to convey rather important diagnostic issues is a bad idea for a variety of reason, not least of which is the fact that the highlighting can be customized in such a way as to render the distinction between scopes invisible. Not to mention the fact that Xcode’s syntax highlighting is especially poor by modern IDE standards, often failing to properly highlight code and susceptible to SourceKit crashes at swiftc’s whim. But even if Xcode’s highlighting had been updated in the last 5 years, it still wouldn’t be a good idea.
  I love the removal of the self requirement, but the aliasing mentioned by Colin Cornaby is a real issue. Rather than requiring self in all instances, perhaps some additional diagnostics would be in line where the compiler detects aliasing against self properties. Of course, there are still contexts in which aliasing is perfectly fine, like an if let, but most of the time it seems like swiftc is rather lax about pointing out shadowing in the name of safety.

Jon Shier

···

On Dec 4, 2015, at 6:37 PM, Kevin Ballard <kevin@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 :slight_smile:

-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@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Tyler Cloutier) #5

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@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 :slight_smile:

-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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(David Hart) #6

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@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@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 :slight_smile:

-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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution