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