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