On Mon, Sep 12, 2016 at 7:05 AM, Eric Gallager <eg...@gwmail.gwu.edu> wrote: > On 9/11/16, Manuel López-Ibáñez <lopeziba...@gmail.com> wrote: >> On 11/09/16 14:02, Mark Wielaard wrote: >>> -Wshadow-local which warns if a local variable shadows another local >>> variable or parameter, >>> >>> -Wshadow-compatible-local which warns if a local variable shadows >>> another local variable or parameter whose type is compatible with that >>> of the shadowing variable.
Hi Mark, Thank you for doing this! >> I honestly don't see the need for the second flag. Why not make Wshadow, or >> at >> least Wshadow-local, work in this way by default? Warning for shadowed >> variables that will nevertheless trigger errors/warnings if used wrongly >> seems not very useful anyway. > > It helps for readability and helps pre-emptively catch those other > errors/warnings that come from using them wrongly before they occur in > a more confusing manner. Plus more granularity makes it easier to > manage the workload of warning-silencing. The new warnings will be especially welcome in C++ code. -Wshadow is fine for most C code, but in C++ it is very common to have method names that shadow class data member names and/or local variables in any member function definition. Thus, using -Wshadow in C++ code often forces undesirable (and unscalable) renaming to avoid such shadowing, while the only important type of shadowing is that caught by the new options. Many of us want the benefit of the new options (spotting bad, easily-fixed code), without having to incur the renaming (often hurting readability/maintainability) required to enable -Werror=shadow.
