Shadowing of members

[Dejan Lekic]

On Wednesday, 9 January 2013 at 21:17:01 UTC, comco wrote:
> 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.

If you use this, then naturally a warning would be ridiculous.

However this should produce a warning:
a = a;
b = b;