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