On 28 October 2016 at 06:57, Paul Smith wrote:
> (using GCC 6.2 on a GNU/Linux system)
>
> I'd love to enable -Wshadow, but unfortunately it gets upset with an
> extremely common idiom in our entire codebase (and lots of other places
> I've worked):
>
> class Foo
> {
> int foo;
> public:
> Foo(int foo) : foo(foo) {}
> };
>
> Here it's very clear what we want and the standard requires that it will
> behave as expected. IMO, this is not appropriate to warn about.
> I can envision more complex initializer lists where things could get
> confusing, if other initializers used the "foo" parameter as well, but
> this one is what is used almost all the time and it's obviously fine.
>
> This issue keeps us from being able to use -Wshadow generally, but
> whenever I do turn it on and trudge through the output (or some small
> subset of the output, before I get tired...) I find code which may not
> be buggy, but is definitely questionable. I'd love to fix the real
> issues and leave this warning on full-time.
>
> Clang has an additional warning flag, -Wshadow-field-in-constructor.
> There, it's not enabled by default with -Wshadow but even if it were in
> GCC and I was able to add -Wno-shadow-field-in-constructor I would be
> happy.
>
> What do people think about making a special case for -Wshadow, either
> that it will never warn for this specific situation (where the parameter
> is used to initialize a member variable of the same name, which would
> cover 90% of my cases) or adding a new option to turn off warnings like
> this in constructor parameters completely, like clang does?
Sounds good to me. I agree there's nothing wrong with the code.
