> This is why I was suggesting earlier in this thread to focus on warnings when > variables and methods are being shadowed, and now to declare in code that a > name is meant to shadow another name. I suspect that (with sufficient > bikeshedding) this would meet the bar for the swift always-on warnings.
I've mentioned in the proposal that the shadowing was discussed, but I believe that making it a mandatory warning would make a lot of mess and unnecessary boilerplate. Imagine UITableViewDataSource or Delegate methods, where each of the methods has tableView argument - which when implemented on UITableViewController (common case) is shadowing self.tableView. What's the solution to this? Rename all of these arguments to aTableView? localTableView? Not to mention that you rename the argument in the function and suddenly, all previous references to the argument refer to self.tableView instead of the argument (if you e.g. forget to use Edit All in Scope) - it would need to be automated and the developer would need to rename a lot of variables... Charlie _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
