Shadowing of members

[Jonathan M Davis]

On Thursday, January 10, 2013 08:17:22 Benjamin Thaut wrote:
> Am 10.01.2013 04:38, schrieb Jonathan M Davis:
> > struct S
> > {
> > 
> >   this(int a, int b)
> >   {
> >   this.a = a;
> >   this.b = b;
> >   }
> >   
> >   int a;
> >   int b;
> > 
> > }
> 
> Please read my original code example. This is not about parameters to
> constructors. It is about local function variables that shadow members.

Same thing. It's just a question of whether the local variable is a parameter 
or not. It's a local variable either way. And my previous point about the only 
time that we make shadowing an error being when you can't actually access the 
variable being shadowed still stands.

I can understand being frustrated by ending up using the wrong variable due to 
shadowing, but there are legitimate cases where making such shadowing a 
warning or error would be _very_ annoying, and there's no technical reason why 
the shadowing is a problem. At worst, it's error-prone. But aside from POD 
types where the variables are public, the normal thing to do is to name 
private member variables slightly differently from other variables (e.g. 
prepending with _), which completely eliminates the problem. I would _much_ 
rather put up with the occasional problem with the shadowing than have the 
compiler complain about my variable names.

- Jonathan M Davis