Re: 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;