Shadowing of members

[Jonathan M Davis]

On Thursday, January 10, 2013 04:24:26 deadalnix wrote:
> 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 ?

1. Walter has already rejected this idea.

2. Do you honestly think that it's not incredibly common to declare 
constructor parameters to have the same names as the member variables that 
they go with? Who _doesn't_ do it that way? The only thing that would mitigate 
how often it would be warned about would be how many POD types in D get away 
without needing to define constructor, because one is implicitly declared. It's 
incredibly common practice in C++, Java. C#, etc. to name constructor 
parameters after the member variables that they go with. If anything, it's 
rare _not_ to do that (aside from private member variables often having stuff 
like _ or m_ added to them).

3. Why on earth would I want the compiler to be warning me about the variable 
names that I pick? No offense. But that's asinine. There are _no_ bugs in code
like

struct S
{
 this(int a, int b)
 {
 this.a = a;
 this.b = b;
 }

 int a;
 int b;
}

There aren't even any _potential_ bugs in that code. It's perfectly sound. 
Warning about something like

a = a;

would make some sense. Warning against a perfectly valid assignment or the 
fact that the variable names happen to be the same is just stupid.

Warning about something which isn't a bug or at least almost a guarantee to be 
a bug is _not_ a valid use of a warning IMHO. You don't have warnings for good 
or bad practice. You have warnings for likely bugs. And I wouldn't even 
consider the struct above to be bad practice anyway.

- Jonathan M Davis