Shadowing of members

[deadalnix]

On Thursday, 10 January 2013 at 03:09:58 UTC, Jonathan M Davis 
wrote:
> On Thursday, January 10, 2013 03:56:10 bearophile wrote:
>> comco:
>> > I won't like this code:
>> > class Pu {
>> > 
>> > int a, b;
>> > this(int a, int b) {
>> > 
>> > this.a = a;
>> > this.b = b;
>> > 
>> > }
>> > 
>> > }
>> > 
>> > to issue warnings for a and b.
>> 
>> That's a nice warning to have, because that's bug-prone code,
>> worth avoiding.
>
> So, basically, you want the compiler to yell at you for picking 
> a bad variable
> name? There's _nothing_ to warn about in the code above. It's 
> perfectly valid.
> I could see warning if you did
>
> this.a = this.a;
>
> or
>
> a = a;
>
> but
>
> this.a = a;
>
> is perfectly valid. And it would be _really_ annoying to not be 
> able to give
> constructor parameters the same names as the member variables 
> that they're
> used to set. Their names will typically differ be a _ if the 
> member variables
> are private, but for POD types, they're almost certainly going 
> to be
> identical, and warning about that would just be stupide.
>
> - Jonathan M Davis

This argument can go on and on forever. What about getting some 
hard data ?

We should start to gather data when considering such issue. What 
about adding the warning in some dmd version and trying it on 
several codebase to get a good view of the impact of such a 
change ?