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

possen · December 15, 2015, 8:31pm

Agreed, I don’t like visual clutter and that is why getting rid of semicolons at the end of the line is really great. If you want to use then you can and I like the suggestion of linters being used to enforce mandatory usage of it if you really want to.

However, I think, it would be ok to use period or “.property” if that does not mess with enums or even “.." (but that starts to get ugly) .

···

On Dec 15, 2015, at 12:03 PM, sune.foldager--- via swift-evolution <swift-evolution@swift.org> wrote:

Personally, I am against using mandatory self. I have coded a lot of Python, and I find it quite annoying to have to type (and read) “self.” everywhere. It’s a balance, of course:

“self.” everywhere means you can see what’s an instance member and what’s a local variable. That’s generally a good thing. But it also means a lot of filler text in your code, which makes reading and writing slower. That’s not so good. It’s a balance, and in this case my experience from C# (and, as mentioned, Python) is that I much prefer C#’s non-mandatory use of “this”/“self".

I see that this proposal is going to be reviewed as SE-0009, and I am a bit concerned that not all arguments are being considered because of the contents of the proposal text: The only counter argument mentioned in the proposal has to do with capturing semantics in closures. This is fine, but why isn’t the counter argument of verbosity being mentioned? This has been brought up on the list as well.

Also, the “Community Responses” section exclusively lists positive feedback. Is that how it’s supposed to be with the SE process? If not, where are the arguments from people who are -1 on the proposal?

I really hope the review team considers:
- The negative responses on this list as well. Also consider that many Swift developers are not on this list; I doubt it’s representative, either, being dominated by “language interested” developers.
- The rather large amount of changes to existing code required.

-Sune

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

Slava_Pestov · December 15, 2015, 10:28pm

Hi all,

I don't see anyone lay out how this proposal can interact with nested types and such. There's a fair amount of complexity in Swift with what you can do by nesting things inside of each other, so the simple conceptual model of "locals are unqualified, instance variables have a self. prefix" doesn't seem to generalize.

Will I need to qualify associated types with the protocol or type name to refer to them? What about generic type parameters, they're sort of like "instance variables" too.

What about class methods that want to call each other? Do they need the explicit 'self', or an explicit class name prefix? The latter changes semantics if the class method is overridden in a subclass.

If we ever add the ability for an inner type to capture stored properties from the outer type, how do you reference properties of the outer type? I guess the problem has to be solved anyway to refer to an outer "self" explicitly, but qualifying everything with OuterType.self.foo kind of defeats the purpose of inner types altogether.

I'm not sure I buy the readability arguments in favor of this approach. It seems the languages where explicit 'self' was adopted did it mostly by accident, or because of implementation concerns. In Python for instance, there's no way for assignment to modify a binding in an outer scope, so 'foo = bar' always sets a local named 'foo', IIRC. So explicit self is needed there. Greg Parker explains earlier in this thread by explicit self was chosen for Objective-C, and it wasn't readability.

Slava

Preston_Sumner · December 15, 2015, 10:09pm

I suspect people would use local variable boilerplates to circumvent mandatory self, as they do in Objective-C.

let a = self.a
let b = self.b
let c = self.c

// Actually do stuff with a, b, and c.

Preston

···

On Dec 15, 2015, at 1:03 PM, sune.foldager--- via swift-evolution <swift-evolution@swift.org> wrote:

Personally, I am against using mandatory self. I have coded a lot of Python, and I find it quite annoying to have to type (and read) “self.” everywhere. It’s a balance, of course:

“self.” everywhere means you can see what’s an instance member and what’s a local variable. That’s generally a good thing. But it also means a lot of filler text in your code, which makes reading and writing slower. That’s not so good. It’s a balance, and in this case my experience from C# (and, as mentioned, Python) is that I much prefer C#’s non-mandatory use of “this”/“self".

I see that this proposal is going to be reviewed as SE-0009, and I am a bit concerned that not all arguments are being considered because of the contents of the proposal text: The only counter argument mentioned in the proposal has to do with capturing semantics in closures. This is fine, but why isn’t the counter argument of verbosity being mentioned? This has been brought up on the list as well.

Also, the “Community Responses” section exclusively lists positive feedback. Is that how it’s supposed to be with the SE process? If not, where are the arguments from people who are -1 on the proposal?

I really hope the review team considers:
- The negative responses on this list as well. Also consider that many Swift developers are not on this list; I doubt it’s representative, either, being dominated by “language interested” developers.
- The rather large amount of changes to existing code required.

-Sune

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

stephencelis · December 15, 2015, 8:12pm

Good points. Ideally the official review period will have members bring up
these counterpoints again.

SE-0009 also misses another "alternative considered" on this list:
prohibiting "self" outside of capture semantics, however impractical it may
be. Should scheduled proposals, as written, be open to amendment before
review?

Stephen

···

On Tue, Dec 15, 2015 at 3:03 PM, sune.foldager--- via swift-evolution < swift-evolution@swift.org> wrote:

I see that this proposal is going to be reviewed as SE-0009, and I am a
bit concerned that not all arguments are being considered because of the
contents of the proposal text: The only counter argument mentioned in the
proposal has to do with capturing semantics in closures. This is fine, but
why isn’t the counter argument of verbosity being mentioned? This has been
brought up on the list as well.

Ash_Furrow · December 15, 2015, 10:16pm

Agreed – there are a few different disadvantages to adopting this new behaviour that aren’t discussed or mentioned at all. Especially considering the confusion from newcomers who do try to use the `let a = self.a` shortcut on value types…

Ash

I suspect people would use local variable boilerplates to circumvent mandatory self, as they do in Objective-C.

let a = self.a
let b = self.b
let c = self.c

// Actually do stuff with a, b, and c.

Preston

···

On December 15, 2015 at 5:09:40 PM, Preston Sumner via swift-evolution (swift-evolution@swift.org) wrote:

On Dec 15, 2015, at 1:03 PM, sune.foldager--- via swift-evolution <swift-evolution@swift.org> wrote:

Personally, I am against using mandatory self. I have coded a lot of Python, and I find it quite annoying to have to type (and read) “self.” everywhere. It’s a balance, of course:

“self.” everywhere means you can see what’s an instance member and what’s a local variable. That’s generally a good thing. But it also means a lot of filler text in your code, which makes reading and writing slower. That’s not so good. It’s a balance, and in this case my experience from C# (and, as mentioned, Python) is that I much prefer C#’s non-mandatory use of “this”/“self".

I see that this proposal is going to be reviewed as SE-0009, and I am a bit concerned that not all arguments are being considered because of the contents of the proposal text: The only counter argument mentioned in the proposal has to do with capturing semantics in closures. This is fine, but why isn’t the counter argument of verbosity being mentioned? This has been brought up on the list as well.

Also, the “Community Responses” section exclusively lists positive feedback. Is that how it’s supposed to be with the SE process? If not, where are the arguments from people who are -1 on the proposal?

I really hope the review team considers:
- The negative responses on this list as well. Also consider that many Swift developers are not on this list; I doubt it’s representative, either, being dominated by “language interested” developers.
- The rather large amount of changes to existing code required.

-Sune

_______________________________________________
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

James_Campbell · December 15, 2015, 10:39pm

I think this should be extended to functions as well. How would you know
the difference between a global function and a class function ?

···

On Tue, Dec 15, 2015 at 10:28 PM, Slava Pestov via swift-evolution < swift-evolution@swift.org> wrote:

Hi all,

I don't see anyone lay out how this proposal can interact with nested
types and such. There's a fair amount of complexity in Swift with what you
can do by nesting things inside of each other, so the simple conceptual
model of "locals are unqualified, instance variables have a self. prefix"
doesn't seem to generalize.

Will I need to qualify associated types with the protocol or type name to
refer to them? What about generic type parameters, they're sort of like
"instance variables" too.

What about class methods that want to call each other? Do they need the
explicit 'self', or an explicit class name prefix? The latter changes
semantics if the class method is overridden in a subclass.

If we ever add the ability for an inner type to capture stored properties
from the outer type, how do you reference properties of the outer type? I
guess the problem has to be solved anyway to refer to an outer "self"
explicitly, but qualifying everything with OuterType.self.foo kind of
defeats the purpose of inner types altogether.

I'm not sure I buy the readability arguments in favor of this approach. It
seems the languages where explicit 'self' was adopted did it mostly by
accident, or because of implementation concerns. In Python for instance,
there's no way for assignment to modify a binding in an outer scope, so
'foo = bar' always sets a local named 'foo', IIRC. So explicit self is
needed there. Greg Parker explains earlier in this thread by explicit self
was chosen for Objective-C, and it wasn't readability.

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

--
 Wizard
james@supmenow.com
+44 7523 279 698

Honza_Dvorsky · December 15, 2015, 10:46pm

Hi all,

I've been following the thread from the beginning and some great arguments
have been layed out. As far as I understand, this proposal would lead to
fewer correctness bugs (referring to a different variable due to implicit
self, has happened to me twice in the last couple of months, was very hard
to track down).

The disadvantages of this are only verbosity. But, from the design
principles of Swift (as I understand them), correctness is preferred over
making the language concise, especially when those two are in conflict,
just like here.

I support the proposal, because it would lead to fewer bugs at only the
cost of extra few characters. Again, I've been bitten by implicit self a
couple times before and those bugs are hard to track down. And the
readability of the code in code reviews, to me, is another huge advantage,
possibly leading to more correctness bugs caught early.

I understand and appreciate the disadvantages, but again, I believe we
should prefer correctness over conciseness, as explicitly stated by the
Swift design principles.

···

On Tue, Dec 15, 2015 at 11:28 PM Slava Pestov via swift-evolution < swift-evolution@swift.org> wrote:

Hi all,

I don't see anyone lay out how this proposal can interact with nested
types and such. There's a fair amount of complexity in Swift with what you
can do by nesting things inside of each other, so the simple conceptual
model of "locals are unqualified, instance variables have a self. prefix"
doesn't seem to generalize.

Will I need to qualify associated types with the protocol or type name to
refer to them? What about generic type parameters, they're sort of like
"instance variables" too.

What about class methods that want to call each other? Do they need the
explicit 'self', or an explicit class name prefix? The latter changes
semantics if the class method is overridden in a subclass.

If we ever add the ability for an inner type to capture stored properties
from the outer type, how do you reference properties of the outer type? I
guess the problem has to be solved anyway to refer to an outer "self"
explicitly, but qualifying everything with OuterType.self.foo kind of
defeats the purpose of inner types altogether.

I'm not sure I buy the readability arguments in favor of this approach. It
seems the languages where explicit 'self' was adopted did it mostly by
accident, or because of implementation concerns. In Python for instance,
there's no way for assignment to modify a binding in an outer scope, so
'foo = bar' always sets a local named 'foo', IIRC. So explicit self is
needed there. Greg Parker explains earlier in this thread by explicit self
was chosen for Objective-C, and it wasn't readability.

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

stephencelis · December 16, 2015, 12:48pm

Will I need to qualify associated types with the protocol or type name to refer to them? What about generic type parameters, they're sort of like "instance variables" too.

Hadn’t thought about that. It does seem that requiring “Self.” would be a natural extension of this proposal.

···

On Dec 15, 2015, at 5:28 PM, Slava Pestov via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 15, 2015, at 5:46 PM, Honza Dvorsky via swift-evolution <swift-evolution@swift.org> wrote:

I've been following the thread from the beginning and some great arguments have been layed out. As far as I understand, this proposal would lead to fewer correctness bugs (referring to a different variable due to implicit self, has happened to me twice in the last couple of months, was very hard to track down).

It sounds to me that the biggest advantage of requiring self is to avoid the occasional , hard-to-find bug (at the cost of muddying the readability of a lot of code). I’d much rather focus on improving compiler diagnostics and error messaging than limit the expressiveness of the language.

With the current discussion having a lot of voices on both sides, I can’t imagine this proposal passing, especially when a linter could easily enforce such a rule for the audience that prefers it.

Stephen

Taras_Zakharko1 · December 16, 2015, 1:55pm

I think the most important advantage of explicit self is that it vastly simplifies the scoping rules of the language as it moves the instance scope into a clearly recognisable construction. As far as I am concerned, self should be mandatory. However, I can also understand that sometimes it might get a bit repetitive (especially when initialising state). This thread is getting a bit large, so sorry if I missed, but did anyone already suggest to introduce a scope operator, which would bind a particular instance to the top of the variable scope. Such operator could be integrated into the existing do, e.g.

do with self { // or with self do
x = 1
y = 2
}

similarly

do with obj {
x = 1
y= 2
}

This has the benefit of keeping the scoping rules simple, preventing clashes between the instance scope and the block/function/global scope, while retaining the possibility to use the ‘more readable’ form if needed. Furthermore, it can be also seen as a neat logical ‘grouping' construct that aids the programmer in understanding the code better.

Again, I apologise if this suggestion was already made, I might have overlooked it.

Best,

Taras

···

-DW

On Dec 15, 2015, at 3:46 PM, Honza Dvorsky via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi all,

I've been following the thread from the beginning and some great arguments have been layed out. As far as I understand, this proposal would lead to fewer correctness bugs (referring to a different variable due to implicit self, has happened to me twice in the last couple of months, was very hard to track down).

The disadvantages of this are only verbosity. But, from the design principles of Swift (as I understand them), correctness is preferred over making the language concise, especially when those two are in conflict, just like here.

I support the proposal, because it would lead to fewer bugs at only the cost of extra few characters. Again, I've been bitten by implicit self a couple times before and those bugs are hard to track down. And the readability of the code in code reviews, to me, is another huge advantage, possibly leading to more correctness bugs caught early.

I understand and appreciate the disadvantages, but again, I believe we should prefer correctness over conciseness, as explicitly stated by the Swift design principles.
On Tue, Dec 15, 2015 at 11:28 PM Slava Pestov via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hi all,

I don't see anyone lay out how this proposal can interact with nested types and such. There's a fair amount of complexity in Swift with what you can do by nesting things inside of each other, so the simple conceptual model of "locals are unqualified, instance variables have a self. prefix" doesn't seem to generalize.

Will I need to qualify associated types with the protocol or type name to refer to them? What about generic type parameters, they're sort of like "instance variables" too.

What about class methods that want to call each other? Do they need the explicit 'self', or an explicit class name prefix? The latter changes semantics if the class method is overridden in a subclass.

If we ever add the ability for an inner type to capture stored properties from the outer type, how do you reference properties of the outer type? I guess the problem has to be solved anyway to refer to an outer "self" explicitly, but qualifying everything with OuterType.self.foo kind of defeats the purpose of inner types altogether.

I'm not sure I buy the readability arguments in favor of this approach. It seems the languages where explicit 'self' was adopted did it mostly by accident, or because of implementation concerns. In Python for instance, there's no way for assignment to modify a binding in an outer scope, so 'foo = bar' always sets a local named 'foo', IIRC. So explicit self is needed there. Greg Parker explains earlier in this thread by explicit self was chosen for Objective-C, and it wasn't readability.

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

Bart_Whiteley · December 14, 2015, 11:52pm

I joined the list late. Apologies for breaking the threading.

From what I understand, the main reason that self is required in closures
and not elsewhere is to serve as a compiler-enforced reminder about the
potential pitfalls of using self within closures (which I happen to think
it does well). Unless and until a different way of calling out those
pitfalls is proposed and accepted (as Andrew was suggesting), that point is
an essential part of the discussion IMO.

...

And on the con side, I have heard --

You forgot "Makes capture semantics of using self inside of closures less
apparent." I consider this the main con of the current proposal, and it
seems others do as well.

A means of preventing retain cycles due to closures should not be
limited to `self`. The same pitfalls apply to other variables.

    var obj = …
    obj.closure = {
        obj.doSomething()
    }

···

On Mon, Dec 14, 2015, 12:30 AM Nick Shelley <nickmshelley at gmail.com> wrote:

--
bart

Slava_Pestov · December 15, 2015, 10:43pm

I think this should be extended to functions as well. How would you know the difference between a global function and a class function ?

We could take this to its logical extreme and require explicit capture lists for all closures, and some kind of prefix (outer.) on captured variable accesses inside closure bodies. :-)

However, nobody would seriously propose this these days, because prevailing wisdom is that functions should be short and easy to read at a glance, especially if they involved nested functions, making it clear what values are captured where and so on.

Why don't we push the same philosophy for classes also?

I'm not just convinced that syntactic disambiguation of scope lookup is desirable...

Slava

···

On Dec 15, 2015, at 2:39 PM, James Campbell <james@supmenow.com> wrote:

On Tue, Dec 15, 2015 at 10:28 PM, Slava Pestov via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hi all,

I don't see anyone lay out how this proposal can interact with nested types and such. There's a fair amount of complexity in Swift with what you can do by nesting things inside of each other, so the simple conceptual model of "locals are unqualified, instance variables have a self. prefix" doesn't seem to generalize.

Will I need to qualify associated types with the protocol or type name to refer to them? What about generic type parameters, they're sort of like "instance variables" too.

What about class methods that want to call each other? Do they need the explicit 'self', or an explicit class name prefix? The latter changes semantics if the class method is overridden in a subclass.

If we ever add the ability for an inner type to capture stored properties from the outer type, how do you reference properties of the outer type? I guess the problem has to be solved anyway to refer to an outer "self" explicitly, but qualifying everything with OuterType.self.foo kind of defeats the purpose of inner types altogether.

I'm not sure I buy the readability arguments in favor of this approach. It seems the languages where explicit 'self' was adopted did it mostly by accident, or because of implementation concerns. In Python for instance, there's no way for assignment to modify a binding in an outer scope, so 'foo = bar' always sets a local named 'foo', IIRC. So explicit self is needed there. Greg Parker explains earlier in this thread by explicit self was chosen for Objective-C, and it wasn't readability.

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

--
 Wizard
james@supmenow.com <mailto:james@supmenow.com>
+44 7523 279 698

dwaite · December 16, 2015, 12:19am

I propose an alternative:
- all functions are expected to possibly strongly capture self (regardless of whether self is used within the closure explicitly or implicitly or not at all) unless it decides due to optimization that the code does not need a strong capture of self. The developer responsible for declaring other behavior, with directives such as [weak self].
- compiler generates warnings if a declared variable or bound parameter shadows a variable/property/method in higher scope, excluding let x = x and the ignored value _.
- These warnings would be generated lazily (so conflicts are reported on use, not declaration). You can reference the self side of the conflict explicitly to resolve the warning.

The disadvantage of explicit self is not just verbosity. It provides noise that interferes with the reading and understanding of the code. Correctness goes beyond Safety (which this proposal doesn’t really address) or Unambiguity IMHO, into the ability to understand the actual underlying algorithm. Yes, I’m saying that sometimes correctness is also conciseness, because the reader of the code needs to be able to understand what it does just as much as they need that understanding to be unambiguous.

-DW

···

On Dec 15, 2015, at 3:46 PM, Honza Dvorsky via swift-evolution <swift-evolution@swift.org> wrote:

Hi all,

I've been following the thread from the beginning and some great arguments have been layed out. As far as I understand, this proposal would lead to fewer correctness bugs (referring to a different variable due to implicit self, has happened to me twice in the last couple of months, was very hard to track down).

The disadvantages of this are only verbosity. But, from the design principles of Swift (as I understand them), correctness is preferred over making the language concise, especially when those two are in conflict, just like here.

I support the proposal, because it would lead to fewer bugs at only the cost of extra few characters. Again, I've been bitten by implicit self a couple times before and those bugs are hard to track down. And the readability of the code in code reviews, to me, is another huge advantage, possibly leading to more correctness bugs caught early.

I understand and appreciate the disadvantages, but again, I believe we should prefer correctness over conciseness, as explicitly stated by the Swift design principles.
On Tue, Dec 15, 2015 at 11:28 PM Slava Pestov via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hi all,

I don't see anyone lay out how this proposal can interact with nested types and such. There's a fair amount of complexity in Swift with what you can do by nesting things inside of each other, so the simple conceptual model of "locals are unqualified, instance variables have a self. prefix" doesn't seem to generalize.

Will I need to qualify associated types with the protocol or type name to refer to them? What about generic type parameters, they're sort of like "instance variables" too.

What about class methods that want to call each other? Do they need the explicit 'self', or an explicit class name prefix? The latter changes semantics if the class method is overridden in a subclass.

If we ever add the ability for an inner type to capture stored properties from the outer type, how do you reference properties of the outer type? I guess the problem has to be solved anyway to refer to an outer "self" explicitly, but qualifying everything with OuterType.self.foo kind of defeats the purpose of inner types altogether.

I'm not sure I buy the readability arguments in favor of this approach. It seems the languages where explicit 'self' was adopted did it mostly by accident, or because of implementation concerns. In Python for instance, there's no way for assignment to modify a binding in an outer scope, so 'foo = bar' always sets a local named 'foo', IIRC. So explicit self is needed there. Greg Parker explains earlier in this thread by explicit self was chosen for Objective-C, and it wasn't readability.

Slava
_______________________________________________
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

dwaite · December 16, 2015, 12:19am

I propose an alternative:
- all functions are expected to possibly strongly capture self (regardless of whether self is used within the closure explicitly or implicitly or not at all) unless it decides due to optimization that the code does not need a strong capture of self. The developer responsible for declaring other behavior, with directives such as [weak self].
- compiler generates warnings if a declared variable or bound parameter shadows a variable/property/method in higher scope, excluding let x = x and the ignored value _.
- These warnings would be generated lazily (so conflicts are reported on use, not declaration). You can reference the self side of the conflict explicitly to resolve the warning.

The disadvantage of explicit self is not just verbosity. It provides noise that interferes with the reading and understanding of the code. Correctness goes beyond Safety (which this proposal doesn’t really address) or Unambiguity IMHO, into the ability to understand the actual underlying algorithm. Yes, I’m saying that sometimes correctness is also conciseness, because the reader of the code needs to be able to understand what it does just as much as they need that understanding to be unambiguous.

-DW

···

On Dec 15, 2015, at 3:46 PM, Honza Dvorsky via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi all,

I've been following the thread from the beginning and some great arguments have been layed out. As far as I understand, this proposal would lead to fewer correctness bugs (referring to a different variable due to implicit self, has happened to me twice in the last couple of months, was very hard to track down).

The disadvantages of this are only verbosity. But, from the design principles of Swift (as I understand them), correctness is preferred over making the language concise, especially when those two are in conflict, just like here.

I support the proposal, because it would lead to fewer bugs at only the cost of extra few characters. Again, I've been bitten by implicit self a couple times before and those bugs are hard to track down. And the readability of the code in code reviews, to me, is another huge advantage, possibly leading to more correctness bugs caught early.

I understand and appreciate the disadvantages, but again, I believe we should prefer correctness over conciseness, as explicitly stated by the Swift design principles.
On Tue, Dec 15, 2015 at 11:28 PM Slava Pestov via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hi all,

I don't see anyone lay out how this proposal can interact with nested types and such. There's a fair amount of complexity in Swift with what you can do by nesting things inside of each other, so the simple conceptual model of "locals are unqualified, instance variables have a self. prefix" doesn't seem to generalize.

Will I need to qualify associated types with the protocol or type name to refer to them? What about generic type parameters, they're sort of like "instance variables" too.

What about class methods that want to call each other? Do they need the explicit 'self', or an explicit class name prefix? The latter changes semantics if the class method is overridden in a subclass.

If we ever add the ability for an inner type to capture stored properties from the outer type, how do you reference properties of the outer type? I guess the problem has to be solved anyway to refer to an outer "self" explicitly, but qualifying everything with OuterType.self.foo kind of defeats the purpose of inner types altogether.

I'm not sure I buy the readability arguments in favor of this approach. It seems the languages where explicit 'self' was adopted did it mostly by accident, or because of implementation concerns. In Python for instance, there's no way for assignment to modify a binding in an outer scope, so 'foo = bar' always sets a local named 'foo', IIRC. So explicit self is needed there. Greg Parker explains earlier in this thread by explicit self was chosen for Objective-C, and it wasn't readability.

Slava
_______________________________________________
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

Honza_Dvorsky1 · December 15, 2015, 10:53pm

Hi all,

I've been following the thread from the beginning and some great arguments
have been layed out. As far as I understand, this proposal would lead to
fewer correctness bugs (referring to a different variable due to implicit
self, has happened to me twice in the last couple of months, was very hard
to track down).

The disadvantages of this are only verbosity. But, from the design
principles of Swift (as I understand them), correctness is preferred over
making the language concise, especially when those two are in conflict,
just like here.

I support the proposal, because it would lead to fewer bugs at only the
cost of extra few characters. Again, I've been bitten by implicit self a
couple times before and those bugs are hard to track down. And the
readability of the code in code reviews, to me, is another huge advantage,
possibly leading to more correctness bugs caught early.

I understand and appreciate the disadvantages, but again, I believe we
should prefer correctness over conciseness, as explicitly stated by the
Swift design principles.

Honza

(sorry for the possible duplication, having some problems with my email
client :))

David_Rodrigues · December 16, 2015, 12:19am

Hi all,

I understand the reasoning from both sides but this seems clearly something
that don't gathers consensus from a majority of us and for that reason why
should we really remove implicit self?

Swift supports both ways so there's an option to every one of us, no one is
forced to use implicit self neither explicit self, its something that can
(and should) be defined in each project as a convention to follow and
possible enforce using a lint.

And if we're really considering removing implicit self to fix a few
potential and hard to track bugs, we may also consider remove the !
operator to force unwrap an optional which is very unsafe unless verified
first (!= nil) when we have a syntax, if let value = value {}, which safely
unwraps the value and can potential prevent a lot of crashes.

It's only a figurative example to illustrate that is hard to achieve full
correctness and while there are options you can choose the one that fits
best to you.

David

···

2015-12-15 22:46 GMT+00:00 Honza Dvorsky via swift-evolution < swift-evolution@swift.org>:

Hi all,

I've been following the thread from the beginning and some great arguments
have been layed out. As far as I understand, this proposal would lead to
fewer correctness bugs (referring to a different variable due to implicit
self, has happened to me twice in the last couple of months, was very hard
to track down).

The disadvantages of this are only verbosity. But, from the design
principles of Swift (as I understand them), correctness is preferred over
making the language concise, especially when those two are in conflict,
just like here.

I support the proposal, because it would lead to fewer bugs at only the
cost of extra few characters. Again, I've been bitten by implicit self a
couple times before and those bugs are hard to track down. And the
readability of the code in code reviews, to me, is another huge advantage,
possibly leading to more correctness bugs caught early.

I understand and appreciate the disadvantages, but again, I believe we
should prefer correctness over conciseness, as explicitly stated by the
Swift design principles.
On Tue, Dec 15, 2015 at 11:28 PM Slava Pestov via swift-evolution < > swift-evolution@swift.org> wrote:

Hi all,

I don't see anyone lay out how this proposal can interact with nested
types and such. There's a fair amount of complexity in Swift with what you
can do by nesting things inside of each other, so the simple conceptual
model of "locals are unqualified, instance variables have a self. prefix"
doesn't seem to generalize.

Will I need to qualify associated types with the protocol or type name to
refer to them? What about generic type parameters, they're sort of like
"instance variables" too.

What about class methods that want to call each other? Do they need the
explicit 'self', or an explicit class name prefix? The latter changes
semantics if the class method is overridden in a subclass.

If we ever add the ability for an inner type to capture stored properties
from the outer type, how do you reference properties of the outer type? I
guess the problem has to be solved anyway to refer to an outer "self"
explicitly, but qualifying everything with OuterType.self.foo kind of
defeats the purpose of inner types altogether.

I'm not sure I buy the readability arguments in favor of this approach.
It seems the languages where explicit 'self' was adopted did it mostly by
accident, or because of implementation concerns. In Python for instance,
there's no way for assignment to modify a binding in an outer scope, so
'foo = bar' always sets a local named 'foo', IIRC. So explicit self is
needed there. Greg Parker explains earlier in this thread by explicit self
was chosen for Objective-C, and it wasn't readability.

Slava
_______________________________________________
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

Ilya_Belenkiy · December 16, 2015, 1:03pm

+1 for keeping self optional and the argument.

···

--
Ilya Belenkiy
On Wed, Dec 16, 2015 at 7:48 AM Stephen Celis via swift-evolution < swift-evolution@swift.org> wrote:

> On Dec 15, 2015, at 5:28 PM, Slava Pestov via swift-evolution < > swift-evolution@swift.org> wrote:
>
> Will I need to qualify associated types with the protocol or type name
to refer to them? What about generic type parameters, they're sort of like
"instance variables" too.

Hadn’t thought about that. It does seem that requiring “Self.” would be a
natural extension of this proposal.

> On Dec 15, 2015, at 5:46 PM, Honza Dvorsky via swift-evolution < > swift-evolution@swift.org> wrote:
>
> I've been following the thread from the beginning and some great
arguments have been layed out. As far as I understand, this proposal would
lead to fewer correctness bugs (referring to a different variable due to
implicit self, has happened to me twice in the last couple of months, was
very hard to track down).

It sounds to me that the biggest advantage of requiring self is to avoid
the occasional , hard-to-find bug (at the cost of muddying the readability
of a lot of code). I’d much rather focus on improving compiler diagnostics
and error messaging than limit the expressiveness of the language.

With the current discussion having a lot of voices on both sides, I can’t
imagine this proposal passing, especially when a linter could easily
enforce such a rule for the audience that prefers it.

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

Pierre_Monod-Broca1 · December 16, 2015, 3:57pm

-1 also for reasons already listed.

I would even like ways to have more implicit self, like method cascading, closure binding, implicit self in a closure if self is explicitly captured, etc…

···

--
Pierre

Le 16 déc. 2015 à 14:55, Taras Zakharko via swift-evolution <swift-evolution@swift.org> a écrit :

I think the most important advantage of explicit self is that it vastly simplifies the scoping rules of the language as it moves the instance scope into a clearly recognisable construction. As far as I am concerned, self should be mandatory. However, I can also understand that sometimes it might get a bit repetitive (especially when initialising state). This thread is getting a bit large, so sorry if I missed, but did anyone already suggest to introduce a scope operator, which would bind a particular instance to the top of the variable scope. Such operator could be integrated into the existing do, e.g.

do with self { // or with self do
   x = 1
   y = 2
}

similarly

do with obj {
   x = 1
   y= 2
}

This has the benefit of keeping the scoping rules simple, preventing clashes between the instance scope and the block/function/global scope, while retaining the possibility to use the ‘more readable’ form if needed. Furthermore, it can be also seen as a neat logical ‘grouping' construct that aids the programmer in understanding the code better.

Again, I apologise if this suggestion was already made, I might have overlooked it.

Best,

Taras

-DW

On Dec 15, 2015, at 3:46 PM, Honza Dvorsky via swift-evolution <swift-evolution@swift.org> wrote:

Hi all,

I've been following the thread from the beginning and some great arguments have been layed out. As far as I understand, this proposal would lead to fewer correctness bugs (referring to a different variable due to implicit self, has happened to me twice in the last couple of months, was very hard to track down).

The disadvantages of this are only verbosity. But, from the design principles of Swift (as I understand them), correctness is preferred over making the language concise, especially when those two are in conflict, just like here.

I support the proposal, because it would lead to fewer bugs at only the cost of extra few characters. Again, I've been bitten by implicit self a couple times before and those bugs are hard to track down. And the readability of the code in code reviews, to me, is another huge advantage, possibly leading to more correctness bugs caught early.

I understand and appreciate the disadvantages, but again, I believe we should prefer correctness over conciseness, as explicitly stated by the Swift design principles.

On Tue, Dec 15, 2015 at 11:28 PM Slava Pestov via swift-evolution <swift-evolution@swift.org> wrote:
Hi all,

I don't see anyone lay out how this proposal can interact with nested types and such. There's a fair amount of complexity in Swift with what you can do by nesting things inside of each other, so the simple conceptual model of "locals are unqualified, instance variables have a self. prefix" doesn't seem to generalize.

Will I need to qualify associated types with the protocol or type name to refer to them? What about generic type parameters, they're sort of like "instance variables" too.

What about class methods that want to call each other? Do they need the explicit 'self', or an explicit class name prefix? The latter changes semantics if the class method is overridden in a subclass.

If we ever add the ability for an inner type to capture stored properties from the outer type, how do you reference properties of the outer type? I guess the problem has to be solved anyway to refer to an outer "self" explicitly, but qualifying everything with OuterType.self.foo kind of defeats the purpose of inner types altogether.

I'm not sure I buy the readability arguments in favor of this approach. It seems the languages where explicit 'self' was adopted did it mostly by accident, or because of implementation concerns. In Python for instance, there's no way for assignment to modify a binding in an outer scope, so 'foo = bar' always sets a local named 'foo', IIRC. So explicit self is needed there. Greg Parker explains earlier in this thread by explicit self was chosen for Objective-C, and it wasn't readability.

Slava
_______________________________________________
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

David_Rodrigues · December 16, 2015, 4:02pm

Hi Pierre,

there's actually a proposal to do that regarding implicit self in a closure
here:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002628.html
.

- David

···

2015-12-16 15:57 GMT+00:00 Pierre Monod-Broca via swift-evolution < swift-evolution@swift.org>:

-1 also for reasons already listed.

I would even like ways to have more implicit self, like method cascading,
closure binding, implicit self in a closure if self is explicitly captured,
etc…

--
Pierre

Le 16 déc. 2015 à 14:55, Taras Zakharko via swift-evolution < > swift-evolution@swift.org> a écrit :

I think the most important advantage of explicit self is that it vastly
simplifies the scoping rules of the language as it moves the instance scope
into a clearly recognisable construction. As far as I am concerned, self
should be mandatory. However, I can also understand that sometimes it might
get a bit repetitive (especially when initialising state). This thread is
getting a bit large, so sorry if I missed, but did anyone already suggest
to introduce a scope operator, which would bind a particular instance to
the top of the variable scope. Such operator could be integrated into the
existing do, e.g.

do with self { // or with self do
   x = 1
   y = 2
}

similarly

do with obj {
   x = 1
   y= 2
}

This has the benefit of keeping the scoping rules simple, preventing
clashes between the instance scope and the block/function/global scope,
while retaining the possibility to use the ‘more readable’ form if needed.
Furthermore, it can be also seen as a neat logical ‘grouping' construct
that aids the programmer in understanding the code better.

Again, I apologise if this suggestion was already made, I might have
overlooked it.

Best,

Taras

-DW

On Dec 15, 2015, at 3:46 PM, Honza Dvorsky via swift-evolution < > swift-evolution@swift.org> wrote:

Hi all,

I've been following the thread from the beginning and some great arguments
have been layed out. As far as I understand, this proposal would lead to
fewer correctness bugs (referring to a different variable due to implicit
self, has happened to me twice in the last couple of months, was very hard
to track down).

The disadvantages of this are only verbosity. But, from the design
principles of Swift (as I understand them), correctness is preferred over
making the language concise, especially when those two are in conflict,
just like here.

I support the proposal, because it would lead to fewer bugs at only the
cost of extra few characters. Again, I've been bitten by implicit self a
couple times before and those bugs are hard to track down. And the
readability of the code in code reviews, to me, is another huge advantage,
possibly leading to more correctness bugs caught early.

I understand and appreciate the disadvantages, but again, I believe we
should prefer correctness over conciseness, as explicitly stated by the
Swift design principles.
On Tue, Dec 15, 2015 at 11:28 PM Slava Pestov via swift-evolution < > swift-evolution@swift.org> wrote:

Hi all,

I don't see anyone lay out how this proposal can interact with nested
types and such. There's a fair amount of complexity in Swift with what you
can do by nesting things inside of each other, so the simple conceptual
model of "locals are unqualified, instance variables have a self. prefix"
doesn't seem to generalize.

Will I need to qualify associated types with the protocol or type name to
refer to them? What about generic type parameters, they're sort of like
"instance variables" too.

What about class methods that want to call each other? Do they need the
explicit 'self', or an explicit class name prefix? The latter changes
semantics if the class method is overridden in a subclass.

If we ever add the ability for an inner type to capture stored properties
from the outer type, how do you reference properties of the outer type? I
guess the problem has to be solved anyway to refer to an outer "self"
explicitly, but qualifying everything with OuterType.self.foo kind of
defeats the purpose of inner types altogether.

I'm not sure I buy the readability arguments in favor of this approach.
It seems the languages where explicit 'self' was adopted did it mostly by
accident, or because of implementation concerns. In Python for instance,
there's no way for assignment to modify a binding in an outer scope, so
'foo = bar' always sets a local named 'foo', IIRC. So explicit self is
needed there. Greg Parker explains earlier in this thread by explicit self
was chosen for Objective-C, and it wasn't readability.

Slava
_______________________________________________
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

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