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.
