Shadowing of members

[deadalnix]

On Thursday, 10 January 2013 at 07:32:27 UTC, Jonathan M Davis 
wrote:
> 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.
>

If is this is the only usefulness of this feature, it's clearly 
useless. This problem is made up, so solving it is worthless (how 
often do this problem occurs in language whee it is allowed ? I 
can guarantee that this occurred to me way less than hitting the 
dmd error on shadowing).

> 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.
>

I understand what you say here, but is seems to me that this is 
backward rationalization.

I can assure you that is problem is way more common than the one 
you mention above, and so, if a language limitation is required 
for the other one, it is required for that one. Or none is 
required.

Consider also that this is yet another inconsistency, which is a 
bad thing in itself.