Proposal SE-0009 Reconsideration

Evolution Discussion
1

Hi there,

I've been an OS X developer for over a decade now and was a huge fan of ObjC, implementing ObjC runtime into FreeBSD kernel as a intern at Cambridge University and my Masters thesis was a modular ObjC runtime that ran on Win 3.11. With the advance of Swift, it was clear to me, however, that this is a point to say goodbye to ObjC and move to Swift.

And so, I've migrated all my projects over 5 months into Swift, which is over 200 KLOC of code, with one project being 90 KLOC. This has lead unfortunately to various hiccups due to bugs in Swift, Xcode, compiler, where I was unable to build a project for a month, etc. - I've filed 84 bug reports at bugreport.apple.com over the past few months regarding developer tools (including Swift) and have begun closely watching the evolution of Swift.

While I strongly disagree with the rejection of SE-0009, I understood the reasoning that it's a boilerplate to keep adding self. in front of all variables. I personally always refer to self when accessing instance variables (and methods), unless they are private variables starting with underscore. I know the underscore thing isn't very Swift-y, but on the other hand, reading the code you immediately know you are dealing with a private instance variable, not something local.

This was until I spent 2 hours chasing a bug that was caused by the exact issue this proposal was trying to prevent. I was furious.

a) When you read someone elses code and you see myVar.doSomething(), you assume it's refering to a local variable. Which is incredibly confusing, if this is an instance variable. Swift is all about compile-time checks and this is where it fails.

b) If you indeed decide not to go with this proposal, please consider adding a warning option. When you take a look at LLVM warning options, I bet there would be a place for this. Let the user decide. I personally would immediately turn it on on all my projects. Don't make it an error, make it a warning.

I speak to you as someone with quite a huge real-life experience with Swift, mainly in the last year - the question whether to force the reference to self is something that may be dividing the community, but I believe that most people with more developing experience would be all for this. At least as an option.

Sincerely yours,

Krystof Vasa

2

I’ve been wondering if shadowing variable names should just be an error. I know that it’s a very common pattern when unwrapping such as:

if let thing = thing {}

But that not only looks ugly, there’s often better ways to solve this and using different names there would also likely improve clarity anyway. Wouldn’t an error when shadowing any variable name also have prevented this bug without requiring self since there would have been no way for there to be a local variable with the same name? Would that be too restrictive or would it actually further Swift's goals of clarity and safety? I think I could probably argue that making shadowed names a straight up error would improve code quality.

l8r
Sean

···

On May 18, 2016, at 12:09 AM, Krystof Vasa via swift-evolution <swift-evolution@swift.org> wrote:

Hi there,

I've been an OS X developer for over a decade now and was a huge fan of ObjC, implementing ObjC runtime into FreeBSD kernel as a intern at Cambridge University and my Masters thesis was a modular ObjC runtime that ran on Win 3.11. With the advance of Swift, it was clear to me, however, that this is a point to say goodbye to ObjC and move to Swift.

And so, I've migrated all my projects over 5 months into Swift, which is over 200 KLOC of code, with one project being 90 KLOC. This has lead unfortunately to various hiccups due to bugs in Swift, Xcode, compiler, where I was unable to build a project for a month, etc. - I've filed 84 bug reports at bugreport.apple.com over the past few months regarding developer tools (including Swift) and have begun closely watching the evolution of Swift.

While I strongly disagree with the rejection of SE-0009, I understood the reasoning that it's a boilerplate to keep adding self. in front of all variables. I personally always refer to self when accessing instance variables (and methods), unless they are private variables starting with underscore. I know the underscore thing isn't very Swift-y, but on the other hand, reading the code you immediately know you are dealing with a private instance variable, not something local.

This was until I spent 2 hours chasing a bug that was caused by the exact issue this proposal was trying to prevent. I was furious.

a) When you read someone elses code and you see myVar.doSomething(), you assume it's refering to a local variable. Which is incredibly confusing, if this is an instance variable. Swift is all about compile-time checks and this is where it fails.

b) If you indeed decide not to go with this proposal, please consider adding a warning option. When you take a look at LLVM warning options, I bet there would be a place for this. Let the user decide. I personally would immediately turn it on on all my projects. Don't make it an error, make it a warning.

I speak to you as someone with quite a huge real-life experience with Swift, mainly in the last year - the question whether to force the reference to self is something that may be dividing the community, but I believe that most people with more developing experience would be all for this. At least as an option.

Sincerely yours,

Krystof Vasa

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

3

Fully support your opinion. +1 for warning option.
Also, I believe we need a warning (not error as suggested by @Sean in reply to this thread) when type's property shadowed with local variable.

Or do we *really* feel that this code don't require at least a warning ?? :

class A {
     var x = 100

     func f() {
         let x = 10
         print(x)
     }
}

···

On 18.05.2016 8:09, Krystof Vasa via swift-evolution wrote:

Hi there,

I've been an OS X developer for over a decade now and was a huge fan of ObjC, implementing ObjC runtime into FreeBSD kernel as a intern at Cambridge University and my Masters thesis was a modular ObjC runtime that ran on Win 3.11. With the advance of Swift, it was clear to me, however, that this is a point to say goodbye to ObjC and move to Swift.

And so, I've migrated all my projects over 5 months into Swift, which is over 200 KLOC of code, with one project being 90 KLOC. This has lead unfortunately to various hiccups due to bugs in Swift, Xcode, compiler, where I was unable to build a project for a month, etc. - I've filed 84 bug reports at bugreport.apple.com over the past few months regarding developer tools (including Swift) and have begun closely watching the evolution of Swift.

While I strongly disagree with the rejection of SE-0009, I understood the reasoning that it's a boilerplate to keep adding self. in front of all variables. I personally always refer to self when accessing instance variables (and methods), unless they are private variables starting with underscore. I know the underscore thing isn't very Swift-y, but on the other hand, reading the code you immediately know you are dealing with a private instance variable, not something local.

This was until I spent 2 hours chasing a bug that was caused by the exact issue this proposal was trying to prevent. I was furious.

a) When you read someone elses code and you see myVar.doSomething(), you assume it's refering to a local variable. Which is incredibly confusing, if this is an instance variable. Swift is all about compile-time checks and this is where it fails.

b) If you indeed decide not to go with this proposal, please consider adding a warning option. When you take a look at LLVM warning options, I bet there would be a place for this. Let the user decide. I personally would immediately turn it on on all my projects. Don't make it an error, make it a warning.

I speak to you as someone with quite a huge real-life experience with Swift, mainly in the last year - the question whether to force the reference to self is something that may be dividing the community, but I believe that most people with more developing experience would be all for this. At least as an option.

Sincerely yours,

Krystof Vasa

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

4

Since you’re using OSX - CMD + click, jumps to definition.

···

On 18 May 2016, at 07:09, Krystof Vasa via swift-evolution <swift-evolution@swift.org> wrote:

Hi there,

I've been an OS X developer for over a decade now and was a huge fan of ObjC, implementing ObjC runtime into FreeBSD kernel as a intern at Cambridge University and my Masters thesis was a modular ObjC runtime that ran on Win 3.11. With the advance of Swift, it was clear to me, however, that this is a point to say goodbye to ObjC and move to Swift.

And so, I've migrated all my projects over 5 months into Swift, which is over 200 KLOC of code, with one project being 90 KLOC. This has lead unfortunately to various hiccups due to bugs in Swift, Xcode, compiler, where I was unable to build a project for a month, etc. - I've filed 84 bug reports at bugreport.apple.com over the past few months regarding developer tools (including Swift) and have begun closely watching the evolution of Swift.

While I strongly disagree with the rejection of SE-0009, I understood the reasoning that it's a boilerplate to keep adding self. in front of all variables. I personally always refer to self when accessing instance variables (and methods), unless they are private variables starting with underscore. I know the underscore thing isn't very Swift-y, but on the other hand, reading the code you immediately know you are dealing with a private instance variable, not something local.

This was until I spent 2 hours chasing a bug that was caused by the exact issue this proposal was trying to prevent. I was furious.

a) When you read someone elses code and you see myVar.doSomething(), you assume it's refering to a local variable. Which is incredibly confusing, if this is an instance variable. Swift is all about compile-time checks and this is where it fails.

b) If you indeed decide not to go with this proposal, please consider adding a warning option. When you take a look at LLVM warning options, I bet there would be a place for this. Let the user decide. I personally would immediately turn it on on all my projects. Don't make it an error, make it a warning.

I speak to you as someone with quite a huge real-life experience with Swift, mainly in the last year - the question whether to force the reference to self is something that may be dividing the community, but I believe that most people with more developing experience would be all for this. At least as an option.

Sincerely yours,

Krystof Vasa

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

5

That proposal might be one of the first early proposals to really get a lot of attention. My take out of the experience is that people (me included in this case) will yell very loudly if you try to enforce your coding standards through the compiler.

There is an open bug on SwiftLint <Issues · realm/SwiftLint · GitHub; to add a rule that enforces using self to access member variables. It might be worth taking a look.

Félix

···

Le 17 mai 2016 à 22:09:44, Krystof Vasa via swift-evolution <swift-evolution@swift.org> a écrit :

Hi there,

I've been an OS X developer for over a decade now and was a huge fan of ObjC, implementing ObjC runtime into FreeBSD kernel as a intern at Cambridge University and my Masters thesis was a modular ObjC runtime that ran on Win 3.11. With the advance of Swift, it was clear to me, however, that this is a point to say goodbye to ObjC and move to Swift.

And so, I've migrated all my projects over 5 months into Swift, which is over 200 KLOC of code, with one project being 90 KLOC. This has lead unfortunately to various hiccups due to bugs in Swift, Xcode, compiler, where I was unable to build a project for a month, etc. - I've filed 84 bug reports at bugreport.apple.com over the past few months regarding developer tools (including Swift) and have begun closely watching the evolution of Swift.

While I strongly disagree with the rejection of SE-0009, I understood the reasoning that it's a boilerplate to keep adding self. in front of all variables. I personally always refer to self when accessing instance variables (and methods), unless they are private variables starting with underscore. I know the underscore thing isn't very Swift-y, but on the other hand, reading the code you immediately know you are dealing with a private instance variable, not something local.

This was until I spent 2 hours chasing a bug that was caused by the exact issue this proposal was trying to prevent. I was furious.

a) When you read someone elses code and you see myVar.doSomething(), you assume it's refering to a local variable. Which is incredibly confusing, if this is an instance variable. Swift is all about compile-time checks and this is where it fails.

b) If you indeed decide not to go with this proposal, please consider adding a warning option. When you take a look at LLVM warning options, I bet there would be a place for this. Let the user decide. I personally would immediately turn it on on all my projects. Don't make it an error, make it a warning.

I speak to you as someone with quite a huge real-life experience with Swift, mainly in the last year - the question whether to force the reference to self is something that may be dividing the community, but I believe that most people with more developing experience would be all for this. At least as an option.

Sincerely yours,

Krystof Vasa

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

6

And that works about 30% of the time, if you’re being generous.

Charles

···

On May 18, 2016, at 1:20 PM, Karl via swift-evolution <swift-evolution@swift.org> wrote:

Since you’re using OSX - CMD + click, jumps to definition.

On 18 May 2016, at 07:09, Krystof Vasa via swift-evolution <swift-evolution@swift.org> wrote:

Hi there,

I've been an OS X developer for over a decade now and was a huge fan of ObjC, implementing ObjC runtime into FreeBSD kernel as a intern at Cambridge University and my Masters thesis was a modular ObjC runtime that ran on Win 3.11. With the advance of Swift, it was clear to me, however, that this is a point to say goodbye to ObjC and move to Swift.

And so, I've migrated all my projects over 5 months into Swift, which is over 200 KLOC of code, with one project being 90 KLOC. This has lead unfortunately to various hiccups due to bugs in Swift, Xcode, compiler, where I was unable to build a project for a month, etc. - I've filed 84 bug reports at bugreport.apple.com over the past few months regarding developer tools (including Swift) and have begun closely watching the evolution of Swift.

While I strongly disagree with the rejection of SE-0009, I understood the reasoning that it's a boilerplate to keep adding self. in front of all variables. I personally always refer to self when accessing instance variables (and methods), unless they are private variables starting with underscore. I know the underscore thing isn't very Swift-y, but on the other hand, reading the code you immediately know you are dealing with a private instance variable, not something local.

This was until I spent 2 hours chasing a bug that was caused by the exact issue this proposal was trying to prevent. I was furious.

a) When you read someone elses code and you see myVar.doSomething(), you assume it's refering to a local variable. Which is incredibly confusing, if this is an instance variable. Swift is all about compile-time checks and this is where it fails.

b) If you indeed decide not to go with this proposal, please consider adding a warning option. When you take a look at LLVM warning options, I bet there would be a place for this. Let the user decide. I personally would immediately turn it on on all my projects. Don't make it an error, make it a warning.

I speak to you as someone with quite a huge real-life experience with Swift, mainly in the last year - the question whether to force the reference to self is something that may be dividing the community, but I believe that most people with more developing experience would be all for this. At least as an option.

Sincerely yours,

Krystof Vasa

_______________________________________________
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

7

I always thought that requiring self everywhere was a red herring, and that what was really needed was clearer use of shadowing. But “if let x = x” is a case of the developer asking for shadowing. So either:
- shadowing only causes warnings in some places and is allowed in others (and has a way to indicate intent to turn off warnings)
- shadowing is disallowed everywhere, and “if let” has some terse syntax to indicate intent.

-DW

···

On May 18, 2016, at 10:39 AM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

Fully support your opinion. +1 for warning option.
Also, I believe we need a warning (not error as suggested by @Sean in reply to this thread) when type's property shadowed with local variable.

Or do we *really* feel that this code don't require at least a warning ?? :

class A {
   var x = 100

   func f() {
       let x = 10
       print(x)
   }
}

On 18.05.2016 8:09, Krystof Vasa via swift-evolution wrote:

Hi there,

I've been an OS X developer for over a decade now and was a huge fan of ObjC, implementing ObjC runtime into FreeBSD kernel as a intern at Cambridge University and my Masters thesis was a modular ObjC runtime that ran on Win 3.11. With the advance of Swift, it was clear to me, however, that this is a point to say goodbye to ObjC and move to Swift.

And so, I've migrated all my projects over 5 months into Swift, which is over 200 KLOC of code, with one project being 90 KLOC. This has lead unfortunately to various hiccups due to bugs in Swift, Xcode, compiler, where I was unable to build a project for a month, etc. - I've filed 84 bug reports at bugreport.apple.com over the past few months regarding developer tools (including Swift) and have begun closely watching the evolution of Swift.

While I strongly disagree with the rejection of SE-0009, I understood the reasoning that it's a boilerplate to keep adding self. in front of all variables. I personally always refer to self when accessing instance variables (and methods), unless they are private variables starting with underscore. I know the underscore thing isn't very Swift-y, but on the other hand, reading the code you immediately know you are dealing with a private instance variable, not something local.

This was until I spent 2 hours chasing a bug that was caused by the exact issue this proposal was trying to prevent. I was furious.

a) When you read someone elses code and you see myVar.doSomething(), you assume it's refering to a local variable. Which is incredibly confusing, if this is an instance variable. Swift is all about compile-time checks and this is where it fails.

b) If you indeed decide not to go with this proposal, please consider adding a warning option. When you take a look at LLVM warning options, I bet there would be a place for this. Let the user decide. I personally would immediately turn it on on all my projects. Don't make it an error, make it a warning.

I speak to you as someone with quite a huge real-life experience with Swift, mainly in the last year - the question whether to force the reference to self is something that may be dividing the community, but I believe that most people with more developing experience would be all for this. At least as an option.

Sincerely yours,

Krystof Vasa

_______________________________________________
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

8

There's shadowing and shadowing.

With instance variables, making this an error isn't a great idea. This will lead to people using "localTableView" instead of just "tableView" which IMHO leads to a code that's not easily readable. In 90% of cases, the issue is that you use something very generic such as the tableView, result, response, etc. How to name it to make more sense? localTableView? myResult, resultOfThisFunction?

BTW the issue I've mentioned earlier that I was chasing for two hours was due to refactoring - I was refactoring a larger method into several smaller ones - and you don't retype the code, you copy-paste it (darn you, copy paste!). And I had a local variable that was incidently the same name as instance variable - and the compiler compiled it since `self` was not required. These kinds of things are then bugs hard to catch and IMHO this is not in line with Swift emphasizing compile-time safety (even though this is not related to type-safety).

I believe that making the proposal an optional warning you can turn on/off on the compiler will satisfy both camps - it will not be required for those who do not want this "safety", yet those who wish to keep on the safe side would simply turn this on.

Krystof

···

On May 18, 2016, at 6:13 PM, Sean Heber via swift-evolution <swift-evolution@swift.org> wrote:

I’ve been wondering if shadowing variable names should just be an error. I know that it’s a very common pattern when unwrapping such as:

if let thing = thing {}

But that not only looks ugly, there’s often better ways to solve this and using different names there would also likely improve clarity anyway. Wouldn’t an error when shadowing any variable name also have prevented this bug without requiring self since there would have been no way for there to be a local variable with the same name? Would that be too restrictive or would it actually further Swift's goals of clarity and safety? I think I could probably argue that making shadowed names a straight up error would improve code quality.

l8r
Sean

On May 18, 2016, at 12:09 AM, Krystof Vasa via swift-evolution <swift-evolution@swift.org> wrote:

Hi there,

I've been an OS X developer for over a decade now and was a huge fan of ObjC, implementing ObjC runtime into FreeBSD kernel as a intern at Cambridge University and my Masters thesis was a modular ObjC runtime that ran on Win 3.11. With the advance of Swift, it was clear to me, however, that this is a point to say goodbye to ObjC and move to Swift.

And so, I've migrated all my projects over 5 months into Swift, which is over 200 KLOC of code, with one project being 90 KLOC. This has lead unfortunately to various hiccups due to bugs in Swift, Xcode, compiler, where I was unable to build a project for a month, etc. - I've filed 84 bug reports at bugreport.apple.com over the past few months regarding developer tools (including Swift) and have begun closely watching the evolution of Swift.

While I strongly disagree with the rejection of SE-0009, I understood the reasoning that it's a boilerplate to keep adding self. in front of all variables. I personally always refer to self when accessing instance variables (and methods), unless they are private variables starting with underscore. I know the underscore thing isn't very Swift-y, but on the other hand, reading the code you immediately know you are dealing with a private instance variable, not something local.

This was until I spent 2 hours chasing a bug that was caused by the exact issue this proposal was trying to prevent. I was furious.

a) When you read someone elses code and you see myVar.doSomething(), you assume it's refering to a local variable. Which is incredibly confusing, if this is an instance variable. Swift is all about compile-time checks and this is where it fails.

b) If you indeed decide not to go with this proposal, please consider adding a warning option. When you take a look at LLVM warning options, I bet there would be a place for this. Let the user decide. I personally would immediately turn it on on all my projects. Don't make it an error, make it a warning.

I speak to you as someone with quite a huge real-life experience with Swift, mainly in the last year - the question whether to force the reference to self is something that may be dividing the community, but I believe that most people with more developing experience would be all for this. At least as an option.

Sincerely yours,

Krystof Vasa

_______________________________________________
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

9

For this, maybe. But consider e.g. UITableViewDelegate methods. They have a "tableView" variable within the method parameters.

When you implement this on UITableViewController, you get automatically a shadowed variable:

class MyController: UITableViewController {

  func tableView(tableView: UITableView, didSelectRowAtIndexPath indexPath: NSIndexPath) {
    /// tableView here can mean both self.tableView and tableView in the method parameters
  }

}

So making variable shadowing warnings/errors isn't as easy. You'd then need to make it something like:

func tableView(aTableView: UITableView, ...) {
  aTableView.reloadData()
}

BTW there is a compiler warning for shadowed variabled in LLVM (-Wshadow). But it doesn't seem to be working with Swift.

···

On May 18, 2016, at 6:39 PM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

Fully support your opinion. +1 for warning option.
Also, I believe we need a warning (not error as suggested by @Sean in reply to this thread) when type's property shadowed with local variable.

Or do we *really* feel that this code don't require at least a warning ?? :

class A {
   var x = 100

   func f() {
       let x = 10
       print(x)
   }
}

On 18.05.2016 8:09, Krystof Vasa via swift-evolution wrote:

Hi there,

I've been an OS X developer for over a decade now and was a huge fan of ObjC, implementing ObjC runtime into FreeBSD kernel as a intern at Cambridge University and my Masters thesis was a modular ObjC runtime that ran on Win 3.11. With the advance of Swift, it was clear to me, however, that this is a point to say goodbye to ObjC and move to Swift.

And so, I've migrated all my projects over 5 months into Swift, which is over 200 KLOC of code, with one project being 90 KLOC. This has lead unfortunately to various hiccups due to bugs in Swift, Xcode, compiler, where I was unable to build a project for a month, etc. - I've filed 84 bug reports at bugreport.apple.com over the past few months regarding developer tools (including Swift) and have begun closely watching the evolution of Swift.

While I strongly disagree with the rejection of SE-0009, I understood the reasoning that it's a boilerplate to keep adding self. in front of all variables. I personally always refer to self when accessing instance variables (and methods), unless they are private variables starting with underscore. I know the underscore thing isn't very Swift-y, but on the other hand, reading the code you immediately know you are dealing with a private instance variable, not something local.

This was until I spent 2 hours chasing a bug that was caused by the exact issue this proposal was trying to prevent. I was furious.

a) When you read someone elses code and you see myVar.doSomething(), you assume it's refering to a local variable. Which is incredibly confusing, if this is an instance variable. Swift is all about compile-time checks and this is where it fails.

b) If you indeed decide not to go with this proposal, please consider adding a warning option. When you take a look at LLVM warning options, I bet there would be a place for this. Let the user decide. I personally would immediately turn it on on all my projects. Don't make it an error, make it a warning.

I speak to you as someone with quite a huge real-life experience with Swift, mainly in the last year - the question whether to force the reference to self is something that may be dividing the community, but I believe that most people with more developing experience would be all for this. At least as an option.

Sincerely yours,

Krystof Vasa

_______________________________________________
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

10

Perhaps a better approach to the shadow variables problem is to enable the objc compiler flag -Wshadow to be available in Swift.

In the same way a "requiring self" compiler flag should help enforce self on the programer by always showing a warning when the flag is on.

···

On May 18, 2016, at 9:13 AM, Sean Heber via swift-evolution <swift-evolution@swift.org> wrote:

I’ve been wondering if shadowing variable names should just be an error. I know that it’s a very common pattern when unwrapping such as:

if let thing = thing {}

But that not only looks ugly, there’s often better ways to solve this and using different names there would also likely improve clarity anyway. Wouldn’t an error when shadowing any variable name also have prevented this bug without requiring self since there would have been no way for there to be a local variable with the same name? Would that be too restrictive or would it actually further Swift's goals of clarity and safety? I think I could probably argue that making shadowed names a straight up error would improve code quality.

l8r
Sean

On May 18, 2016, at 12:09 AM, Krystof Vasa via swift-evolution <swift-evolution@swift.org> wrote:

Hi there,

I've been an OS X developer for over a decade now and was a huge fan of ObjC, implementing ObjC runtime into FreeBSD kernel as a intern at Cambridge University and my Masters thesis was a modular ObjC runtime that ran on Win 3.11. With the advance of Swift, it was clear to me, however, that this is a point to say goodbye to ObjC and move to Swift.

And so, I've migrated all my projects over 5 months into Swift, which is over 200 KLOC of code, with one project being 90 KLOC. This has lead unfortunately to various hiccups due to bugs in Swift, Xcode, compiler, where I was unable to build a project for a month, etc. - I've filed 84 bug reports at bugreport.apple.com over the past few months regarding developer tools (including Swift) and have begun closely watching the evolution of Swift.

While I strongly disagree with the rejection of SE-0009, I understood the reasoning that it's a boilerplate to keep adding self. in front of all variables. I personally always refer to self when accessing instance variables (and methods), unless they are private variables starting with underscore. I know the underscore thing isn't very Swift-y, but on the other hand, reading the code you immediately know you are dealing with a private instance variable, not something local.

This was until I spent 2 hours chasing a bug that was caused by the exact issue this proposal was trying to prevent. I was furious.

a) When you read someone elses code and you see myVar.doSomething(), you assume it's refering to a local variable. Which is incredibly confusing, if this is an instance variable. Swift is all about compile-time checks and this is where it fails.

b) If you indeed decide not to go with this proposal, please consider adding a warning option. When you take a look at LLVM warning options, I bet there would be a place for this. Let the user decide. I personally would immediately turn it on on all my projects. Don't make it an error, make it a warning.

I speak to you as someone with quite a huge real-life experience with Swift, mainly in the last year - the question whether to force the reference to self is something that may be dividing the community, but I believe that most people with more developing experience would be all for this. At least as an option.

Sincerely yours,

Krystof Vasa

_______________________________________________
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

11

Sure, but that assumes that you know where the issue is. Since the app compiles and works fine, except for various glitches, you need to debug this (takes time). This is not preventing an issue that shouldn't happen in the first place.

···

On May 18, 2016, at 8:20 PM, Karl via swift-evolution <swift-evolution@swift.org> wrote:

Since you’re using OSX - CMD + click, jumps to definition.

On 18 May 2016, at 07:09, Krystof Vasa via swift-evolution <swift-evolution@swift.org> wrote:

Hi there,

I've been an OS X developer for over a decade now and was a huge fan of ObjC, implementing ObjC runtime into FreeBSD kernel as a intern at Cambridge University and my Masters thesis was a modular ObjC runtime that ran on Win 3.11. With the advance of Swift, it was clear to me, however, that this is a point to say goodbye to ObjC and move to Swift.

And so, I've migrated all my projects over 5 months into Swift, which is over 200 KLOC of code, with one project being 90 KLOC. This has lead unfortunately to various hiccups due to bugs in Swift, Xcode, compiler, where I was unable to build a project for a month, etc. - I've filed 84 bug reports at bugreport.apple.com over the past few months regarding developer tools (including Swift) and have begun closely watching the evolution of Swift.

While I strongly disagree with the rejection of SE-0009, I understood the reasoning that it's a boilerplate to keep adding self. in front of all variables. I personally always refer to self when accessing instance variables (and methods), unless they are private variables starting with underscore. I know the underscore thing isn't very Swift-y, but on the other hand, reading the code you immediately know you are dealing with a private instance variable, not something local.

This was until I spent 2 hours chasing a bug that was caused by the exact issue this proposal was trying to prevent. I was furious.

a) When you read someone elses code and you see myVar.doSomething(), you assume it's refering to a local variable. Which is incredibly confusing, if this is an instance variable. Swift is all about compile-time checks and this is where it fails.

b) If you indeed decide not to go with this proposal, please consider adding a warning option. When you take a look at LLVM warning options, I bet there would be a place for this. Let the user decide. I personally would immediately turn it on on all my projects. Don't make it an error, make it a warning.

I speak to you as someone with quite a huge real-life experience with Swift, mainly in the last year - the question whether to force the reference to self is something that may be dividing the community, but I believe that most people with more developing experience would be all for this. At least as an option.

Sincerely yours,

Krystof Vasa

_______________________________________________
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

12

Hm.. can't check right now.. But can't we change `tableView` parameter name as it is internal name for parameter

func tableView(*theTableView*: UITableView, didSelectRowAtIndexPath indexPath: NSIndexPath) {
}

In any case, I think the problem with shadowing exists and IMO Swift will be better if we'll have some rules about it.

···

On 18.05.2016 19:51, Krystof Vasa wrote:

For this, maybe. But consider e.g. UITableViewDelegate methods. They have a "tableView" variable within the method parameters.

When you implement this on UITableViewController, you get automatically a shadowed variable:

class MyController: UITableViewController {

  func tableView(tableView: UITableView, didSelectRowAtIndexPath indexPath: NSIndexPath) {
    /// tableView here can mean both self.tableView and tableView in the method parameters
  }

}

So making variable shadowing warnings/errors isn't as easy. You'd then need to make it something like:

func tableView(aTableView: UITableView, ...) {
  aTableView.reloadData()
}

BTW there is a compiler warning for shadowed variabled in LLVM (-Wshadow). But it doesn't seem to be working with Swift.

On May 18, 2016, at 6:39 PM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

Fully support your opinion. +1 for warning option.
Also, I believe we need a warning (not error as suggested by @Sean in reply to this thread) when type's property shadowed with local variable.

Or do we *really* feel that this code don't require at least a warning ?? :

class A {
   var x = 100

   func f() {
       let x = 10
       print(x)
   }
}

On 18.05.2016 8:09, Krystof Vasa via swift-evolution wrote:

Hi there,

I've been an OS X developer for over a decade now and was a huge fan of ObjC, implementing ObjC runtime into FreeBSD kernel as a intern at Cambridge University and my Masters thesis was a modular ObjC runtime that ran on Win 3.11. With the advance of Swift, it was clear to me, however, that this is a point to say goodbye to ObjC and move to Swift.

And so, I've migrated all my projects over 5 months into Swift, which is over 200 KLOC of code, with one project being 90 KLOC. This has lead unfortunately to various hiccups due to bugs in Swift, Xcode, compiler, where I was unable to build a project for a month, etc. - I've filed 84 bug reports at bugreport.apple.com over the past few months regarding developer tools (including Swift) and have begun closely watching the evolution of Swift.

While I strongly disagree with the rejection of SE-0009, I understood the reasoning that it's a boilerplate to keep adding self. in front of all variables. I personally always refer to self when accessing instance variables (and methods), unless they are private variables starting with underscore. I know the underscore thing isn't very Swift-y, but on the other hand, reading the code you immediately know you are dealing with a private instance variable, not something local.

This was until I spent 2 hours chasing a bug that was caused by the exact issue this proposal was trying to prevent. I was furious.

a) When you read someone elses code and you see myVar.doSomething(), you assume it's refering to a local variable. Which is incredibly confusing, if this is an instance variable. Swift is all about compile-time checks and this is where it fails.

b) If you indeed decide not to go with this proposal, please consider adding a warning option. When you take a look at LLVM warning options, I bet there would be a place for this. Let the user decide. I personally would immediately turn it on on all my projects. Don't make it an error, make it a warning.

I speak to you as someone with quite a huge real-life experience with Swift, mainly in the last year - the question whether to force the reference to self is something that may be dividing the community, but I believe that most people with more developing experience would be all for this. At least as an option.

Sincerely yours,

Krystof Vasa

_______________________________________________
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

13

The code you pasted really ought to print a warning out (allowing variable shadowing without even a warning can lead to annoying bugs), a generation of Swift developers will be trained by relying on the Swift compiler to make their code automagically safe and this is another one of those Not Fun To Debug bits (similar to the dispatching rules of protocol extensions default methods).

···

Sent from my iPhone

On 18 May 2016, at 17:39, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

Fully support your opinion. +1 for warning option.
Also, I believe we need a warning (not error as suggested by @Sean in reply to this thread) when type's property shadowed with local variable.

Or do we *really* feel that this code don't require at least a warning ?? :

class A {
   var x = 100

   func f() {
       let x = 10
       print(x)
   }
}

On 18.05.2016 8:09, Krystof Vasa via swift-evolution wrote:
Hi there,

I've been an OS X developer for over a decade now and was a huge fan of ObjC, implementing ObjC runtime into FreeBSD kernel as a intern at Cambridge University and my Masters thesis was a modular ObjC runtime that ran on Win 3.11. With the advance of Swift, it was clear to me, however, that this is a point to say goodbye to ObjC and move to Swift.

And so, I've migrated all my projects over 5 months into Swift, which is over 200 KLOC of code, with one project being 90 KLOC. This has lead unfortunately to various hiccups due to bugs in Swift, Xcode, compiler, where I was unable to build a project for a month, etc. - I've filed 84 bug reports at bugreport.apple.com over the past few months regarding developer tools (including Swift) and have begun closely watching the evolution of Swift.

While I strongly disagree with the rejection of SE-0009, I understood the reasoning that it's a boilerplate to keep adding self. in front of all variables. I personally always refer to self when accessing instance variables (and methods), unless they are private variables starting with underscore. I know the underscore thing isn't very Swift-y, but on the other hand, reading the code you immediately know you are dealing with a private instance variable, not something local.

This was until I spent 2 hours chasing a bug that was caused by the exact issue this proposal was trying to prevent. I was furious.

a) When you read someone elses code and you see myVar.doSomething(), you assume it's refering to a local variable. Which is incredibly confusing, if this is an instance variable. Swift is all about compile-time checks and this is where it fails.

b) If you indeed decide not to go with this proposal, please consider adding a warning option. When you take a look at LLVM warning options, I bet there would be a place for this. Let the user decide. I personally would immediately turn it on on all my projects. Don't make it an error, make it a warning.

I speak to you as someone with quite a huge real-life experience with Swift, mainly in the last year - the question whether to force the reference to self is something that may be dividing the community, but I believe that most people with more developing experience would be all for this. At least as an option.

Sincerely yours,

Krystof Vasa

_______________________________________________
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

14

See my example with the tableView and the UITableViewDelegate on UITableViewController. `if let x = x` isn't the usual case. The usual case is that you have e.g. tableView instance on the class and a method that takes a tableView parameter. Then you change the method signature not to include the parameter and the code still compiles, since the tableView reference now goes to the instance variable, which is wrong.

I agree that shadowing variables is not a good idea, but I stand by my point that it's potentially dangerous and error-prone to allow accessing instance variables without `self`.

Krystof

···

On May 18, 2016, at 9:36 PM, David Waite <david@alkaline-solutions.com> wrote:

I always thought that requiring self everywhere was a red herring, and that what was really needed was clearer use of shadowing. But “if let x = x” is a case of the developer asking for shadowing. So either:
- shadowing only causes warnings in some places and is allowed in others (and has a way to indicate intent to turn off warnings)
- shadowing is disallowed everywhere, and “if let” has some terse syntax to indicate intent.

-DW

On May 18, 2016, at 10:39 AM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

Fully support your opinion. +1 for warning option.
Also, I believe we need a warning (not error as suggested by @Sean in reply to this thread) when type's property shadowed with local variable.

Or do we *really* feel that this code don't require at least a warning ?? :

class A {
  var x = 100

  func f() {
      let x = 10
      print(x)
  }
}

On 18.05.2016 8:09, Krystof Vasa via swift-evolution wrote:

Hi there,

I've been an OS X developer for over a decade now and was a huge fan of ObjC, implementing ObjC runtime into FreeBSD kernel as a intern at Cambridge University and my Masters thesis was a modular ObjC runtime that ran on Win 3.11. With the advance of Swift, it was clear to me, however, that this is a point to say goodbye to ObjC and move to Swift.

And so, I've migrated all my projects over 5 months into Swift, which is over 200 KLOC of code, with one project being 90 KLOC. This has lead unfortunately to various hiccups due to bugs in Swift, Xcode, compiler, where I was unable to build a project for a month, etc. - I've filed 84 bug reports at bugreport.apple.com over the past few months regarding developer tools (including Swift) and have begun closely watching the evolution of Swift.

While I strongly disagree with the rejection of SE-0009, I understood the reasoning that it's a boilerplate to keep adding self. in front of all variables. I personally always refer to self when accessing instance variables (and methods), unless they are private variables starting with underscore. I know the underscore thing isn't very Swift-y, but on the other hand, reading the code you immediately know you are dealing with a private instance variable, not something local.

This was until I spent 2 hours chasing a bug that was caused by the exact issue this proposal was trying to prevent. I was furious.

a) When you read someone elses code and you see myVar.doSomething(), you assume it's refering to a local variable. Which is incredibly confusing, if this is an instance variable. Swift is all about compile-time checks and this is where it fails.

b) If you indeed decide not to go with this proposal, please consider adding a warning option. When you take a look at LLVM warning options, I bet there would be a place for this. Let the user decide. I personally would immediately turn it on on all my projects. Don't make it an error, make it a warning.

I speak to you as someone with quite a huge real-life experience with Swift, mainly in the last year - the question whether to force the reference to self is something that may be dividing the community, but I believe that most people with more developing experience would be all for this. At least as an option.

Sincerely yours,

Krystof Vasa

_______________________________________________
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

15

Thanks for the link, I'll definitely keep my eye on it, though since there are two large camps siding with either side, I don't see the harm making this proposal an optional warning of the compiler that would be off by default and those wanting to stay on the safe side would enable this and get a warning.

BTW another example of what this would prevent:

On OS X, all views (NSView) have a print(_:) method. So whenever you write within your code print("something"), it actually invokes the printing method (since its argument is AnyObject?) - if you indeed want to print something to the console, you need to use Swift.print("something") which is incredibly annoying mostly when you forget about this and all of sudden you get print dialogs instead of a log in the console.

Yes, it's shadowing, but with this one, you can't do anything about and there will always be cases of shadowing - the more dangerous when you don't know about them.

Krystof

···

On May 19, 2016, at 6:32 AM, Félix Cloutier via swift-evolution <swift-evolution@swift.org> wrote:

That proposal might be one of the first early proposals to really get a lot of attention. My take out of the experience is that people (me included in this case) will yell very loudly if you try to enforce your coding standards through the compiler.

There is an open bug on SwiftLint <Issues · realm/SwiftLint · GitHub; to add a rule that enforces using self to access member variables. It might be worth taking a look.

Félix

Le 17 mai 2016 à 22:09:44, Krystof Vasa via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

Hi there,

I've been an OS X developer for over a decade now and was a huge fan of ObjC, implementing ObjC runtime into FreeBSD kernel as a intern at Cambridge University and my Masters thesis was a modular ObjC runtime that ran on Win 3.11. With the advance of Swift, it was clear to me, however, that this is a point to say goodbye to ObjC and move to Swift.

And so, I've migrated all my projects over 5 months into Swift, which is over 200 KLOC of code, with one project being 90 KLOC. This has lead unfortunately to various hiccups due to bugs in Swift, Xcode, compiler, where I was unable to build a project for a month, etc. - I've filed 84 bug reports at bugreport.apple.com <Feedback Assistant; over the past few months regarding developer tools (including Swift) and have begun closely watching the evolution of Swift.

While I strongly disagree with the rejection of SE-0009, I understood the reasoning that it's a boilerplate to keep adding self. in front of all variables. I personally always refer to self when accessing instance variables (and methods), unless they are private variables starting with underscore. I know the underscore thing isn't very Swift-y, but on the other hand, reading the code you immediately know you are dealing with a private instance variable, not something local.

This was until I spent 2 hours chasing a bug that was caused by the exact issue this proposal was trying to prevent. I was furious.

a) When you read someone elses code and you see myVar.doSomething(), you assume it's refering to a local variable. Which is incredibly confusing, if this is an instance variable. Swift is all about compile-time checks and this is where it fails.

b) If you indeed decide not to go with this proposal, please consider adding a warning option. When you take a look at LLVM warning options, I bet there would be a place for this. Let the user decide. I personally would immediately turn it on on all my projects. Don't make it an error, make it a warning.

I speak to you as someone with quite a huge real-life experience with Swift, mainly in the last year - the question whether to force the reference to self is something that may be dividing the community, but I believe that most people with more developing experience would be all for this. At least as an option.

Sincerely yours,

Krystof Vasa

_______________________________________________
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

16

I'd prefer to raise warning for any shadowing, and so, in case of
`if let value = value` we'll have a warning: in discussions about 'if let! value' construction proposal there was many opinions that 'if let v = v' is a bad style and you should avoid to do this and improve your code to not do this. So I believe warning for 'if let v = v' will be accepted by community.

···

On 18.05.2016 22:36, David Waite wrote:

I always thought that requiring self everywhere was a red herring, and that what was really needed was clearer use of shadowing. But “if let x = x” is a case of the developer asking for shadowing. So either:
- shadowing only causes warnings in some places and is allowed in others (and has a way to indicate intent to turn off warnings)
- shadowing is disallowed everywhere, and “if let” has some terse syntax to indicate intent.

-DW

On May 18, 2016, at 10:39 AM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

Fully support your opinion. +1 for warning option.
Also, I believe we need a warning (not error as suggested by @Sean in reply to this thread) when type's property shadowed with local variable.

Or do we *really* feel that this code don't require at least a warning ?? :

class A {
   var x = 100

   func f() {
       let x = 10
       print(x)
   }
}

On 18.05.2016 8:09, Krystof Vasa via swift-evolution wrote:

Hi there,

I've been an OS X developer for over a decade now and was a huge fan of ObjC, implementing ObjC runtime into FreeBSD kernel as a intern at Cambridge University and my Masters thesis was a modular ObjC runtime that ran on Win 3.11. With the advance of Swift, it was clear to me, however, that this is a point to say goodbye to ObjC and move to Swift.

And so, I've migrated all my projects over 5 months into Swift, which is over 200 KLOC of code, with one project being 90 KLOC. This has lead unfortunately to various hiccups due to bugs in Swift, Xcode, compiler, where I was unable to build a project for a month, etc. - I've filed 84 bug reports at bugreport.apple.com over the past few months regarding developer tools (including Swift) and have begun closely watching the evolution of Swift.

While I strongly disagree with the rejection of SE-0009, I understood the reasoning that it's a boilerplate to keep adding self. in front of all variables. I personally always refer to self when accessing instance variables (and methods), unless they are private variables starting with underscore. I know the underscore thing isn't very Swift-y, but on the other hand, reading the code you immediately know you are dealing with a private instance variable, not something local.

This was until I spent 2 hours chasing a bug that was caused by the exact issue this proposal was trying to prevent. I was furious.

a) When you read someone elses code and you see myVar.doSomething(), you assume it's refering to a local variable. Which is incredibly confusing, if this is an instance variable. Swift is all about compile-time checks and this is where it fails.

b) If you indeed decide not to go with this proposal, please consider adding a warning option. When you take a look at LLVM warning options, I bet there would be a place for this. Let the user decide. I personally would immediately turn it on on all my projects. Don't make it an error, make it a warning.

I speak to you as someone with quite a huge real-life experience with Swift, mainly in the last year - the question whether to force the reference to self is something that may be dividing the community, but I believe that most people with more developing experience would be all for this. At least as an option.

Sincerely yours,

Krystof Vasa

_______________________________________________
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

.

17

See my example with the tableView and the UITableViewDelegate on UITableViewController. `if let x = x` isn't the usual case. The usual case is that you have e.g. tableView instance on the class and a method that takes a tableView parameter.

That would be shadowing.

Then you change the method signature not to include the parameter and the code still compiles, since the tableView reference now goes to the instance variable, which is wrong.

If the annotation/keyword behaved similar to ‘override’, then you would either have a shadowing warning before saying that there was shadowing, or afterward saying that you are using the annotation/keyword when shadowing isn’t happening.

I agree that shadowing variables is not a good idea, but I stand by my point that it's potentially dangerous and error-prone to allow accessing instance variables without `self`.

Krystof

-DW

···

On May 18, 2016, at 1:43 PM, Krystof Vasa <kvasa@icloud.com> wrote:

18

The code you pasted really ought to print a warning out (allowing variable shadowing without even a warning can lead to annoying bugs), a generation of Swift developers will be trained by relying on the Swift compiler to make their code automagically safe and this is another one of those Not Fun To Debug bits (similar to the dispatching rules of protocol extensions default methods).

There are dispatching rules of protocol extension default methods? I thought the methods are selected randomly... just kidding - I think this issue would be worth a proposal...

···

Am 18.05.2016 um 21:53 schrieb Goffredo Marocchi via swift-evolution <swift-evolution@swift.org>:

Sent from my iPhone

On 18 May 2016, at 17:39, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

Fully support your opinion. +1 for warning option.
Also, I believe we need a warning (not error as suggested by @Sean in reply to this thread) when type's property shadowed with local variable.

Or do we *really* feel that this code don't require at least a warning ?? :

class A {
  var x = 100

  func f() {
      let x = 10
      print(x)
  }
}

On 18.05.2016 8:09, Krystof Vasa via swift-evolution wrote:
Hi there,

I've been an OS X developer for over a decade now and was a huge fan of ObjC, implementing ObjC runtime into FreeBSD kernel as a intern at Cambridge University and my Masters thesis was a modular ObjC runtime that ran on Win 3.11. With the advance of Swift, it was clear to me, however, that this is a point to say goodbye to ObjC and move to Swift.

And so, I've migrated all my projects over 5 months into Swift, which is over 200 KLOC of code, with one project being 90 KLOC. This has lead unfortunately to various hiccups due to bugs in Swift, Xcode, compiler, where I was unable to build a project for a month, etc. - I've filed 84 bug reports at bugreport.apple.com over the past few months regarding developer tools (including Swift) and have begun closely watching the evolution of Swift.

While I strongly disagree with the rejection of SE-0009, I understood the reasoning that it's a boilerplate to keep adding self. in front of all variables. I personally always refer to self when accessing instance variables (and methods), unless they are private variables starting with underscore. I know the underscore thing isn't very Swift-y, but on the other hand, reading the code you immediately know you are dealing with a private instance variable, not something local.

This was until I spent 2 hours chasing a bug that was caused by the exact issue this proposal was trying to prevent. I was furious.

a) When you read someone elses code and you see myVar.doSomething(), you assume it's refering to a local variable. Which is incredibly confusing, if this is an instance variable. Swift is all about compile-time checks and this is where it fails.

b) If you indeed decide not to go with this proposal, please consider adding a warning option. When you take a look at LLVM warning options, I bet there would be a place for this. Let the user decide. I personally would immediately turn it on on all my projects. Don't make it an error, make it a warning.

I speak to you as someone with quite a huge real-life experience with Swift, mainly in the last year - the question whether to force the reference to self is something that may be dividing the community, but I believe that most people with more developing experience would be all for this. At least as an option.

Sincerely yours,

Krystof Vasa

_______________________________________________
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

19

See my example with the tableView and the UITableViewDelegate on UITableViewController. `if let x = x` isn't the usual case. The usual case is that you have e.g. tableView instance on the class and a method that takes a tableView parameter.

That would be shadowing.

Yes, of course. But if you mark shadowing as error/warning, you need to update dozens if not hundreds of places in your projects since most default argument names in UITableViewController shadow the tableView instance variable.

Then you change the method signature not to include the parameter and the code still compiles, since the tableView reference now goes to the instance variable, which is wrong.

If the annotation/keyword behaved similar to ‘override’, then you would either have a shadowing warning before saying that there was shadowing, or afterward saying that you are using the annotation/keyword when shadowing isn’t happening.

That was just an example - I've written in another email here that the issue I was describing occurred during refactoring a larger method into smaller ones - you retype the code, you copy-paste it. And since reference to an instance variable without refering to self is fine, it may compile even though the semantics changed.

···

I agree that shadowing variables is not a good idea, but I stand by my point that it's potentially dangerous and error-prone to allow accessing instance variables without `self`.

Krystof

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

20

Put me firmly in the pro-warning camp. If enforcing manual synthesis of ivars (something I never understood the brouhaha about) warranted a warning flag in clang, I think requiring self should at least merit consideration. It certainly has a much greater potential for bugs than automatic ivar synthesis.

Charles

···

On May 18, 2016, at 11:44 PM, Krystof Vasa via swift-evolution <swift-evolution@swift.org> wrote:

Thanks for the link, I'll definitely keep my eye on it, though since there are two large camps siding with either side, I don't see the harm making this proposal an optional warning of the compiler that would be off by default and those wanting to stay on the safe side would enable this and get a warning.

BTW another example of what this would prevent:

On OS X, all views (NSView) have a print(_:) method. So whenever you write within your code print("something"), it actually invokes the printing method (since its argument is AnyObject?) - if you indeed want to print something to the console, you need to use Swift.print("something") which is incredibly annoying mostly when you forget about this and all of sudden you get print dialogs instead of a log in the console.

Yes, it's shadowing, but with this one, you can't do anything about and there will always be cases of shadowing - the more dangerous when you don't know about them.

Krystof

On May 19, 2016, at 6:32 AM, Félix Cloutier via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

That proposal might be one of the first early proposals to really get a lot of attention. My take out of the experience is that people (me included in this case) will yell very loudly if you try to enforce your coding standards through the compiler.

There is an open bug on SwiftLint <Issues · realm/SwiftLint · GitHub; to add a rule that enforces using self to access member variables. It might be worth taking a look.

Félix

Le 17 mai 2016 à 22:09:44, Krystof Vasa via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

Hi there,

I've been an OS X developer for over a decade now and was a huge fan of ObjC, implementing ObjC runtime into FreeBSD kernel as a intern at Cambridge University and my Masters thesis was a modular ObjC runtime that ran on Win 3.11. With the advance of Swift, it was clear to me, however, that this is a point to say goodbye to ObjC and move to Swift.

And so, I've migrated all my projects over 5 months into Swift, which is over 200 KLOC of code, with one project being 90 KLOC. This has lead unfortunately to various hiccups due to bugs in Swift, Xcode, compiler, where I was unable to build a project for a month, etc. - I've filed 84 bug reports at bugreport.apple.com <Feedback Assistant; over the past few months regarding developer tools (including Swift) and have begun closely watching the evolution of Swift.

While I strongly disagree with the rejection of SE-0009, I understood the reasoning that it's a boilerplate to keep adding self. in front of all variables. I personally always refer to self when accessing instance variables (and methods), unless they are private variables starting with underscore. I know the underscore thing isn't very Swift-y, but on the other hand, reading the code you immediately know you are dealing with a private instance variable, not something local.

This was until I spent 2 hours chasing a bug that was caused by the exact issue this proposal was trying to prevent. I was furious.

a) When you read someone elses code and you see myVar.doSomething(), you assume it's refering to a local variable. Which is incredibly confusing, if this is an instance variable. Swift is all about compile-time checks and this is where it fails.

b) If you indeed decide not to go with this proposal, please consider adding a warning option. When you take a look at LLVM warning options, I bet there would be a place for this. Let the user decide. I personally would immediately turn it on on all my projects. Don't make it an error, make it a warning.

I speak to you as someone with quite a huge real-life experience with Swift, mainly in the last year - the question whether to force the reference to self is something that may be dividing the community, but I believe that most people with more developing experience would be all for this. At least as an option.

Sincerely yours,

Krystof Vasa

_______________________________________________
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