Shadowing of members

[comco]

On Wednesday, 9 January 2013 at 20:36:16 UTC, Benjamin Thaut 
wrote:
> After some refactoring I had a series of bugs that came from 
> renaming class members so that the following situation was 
> present.
>
>
> class foo
> {
>   float a;
>
>   void doSomething()
>   {
>     float a;
>     a = a * 2.0;
>   }
> }
>
> The local variable a shadows the member a after the refactoring 
> and therefore this code will no longer work as expected. This 
> was quite time consuming to track down. So I wanted to ask if 
> we want to prevent that with a warning or even an error? D does 
> not allow shadowing of local variables, so why is it allowed 
> for members?
>
> Kind Regards
> Benjamin Thaut

I don't think an error will be appropriate, because this a can be 
a protected member of the super-super-super class and it won't be 
nice to be forced to use a different name. But another view on 
this is that it behaves consistently with the case in which a 
function parameter shadows a member.
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.