On Sunday, 20 October 2013 at 01:15:12 UTC, Jonathan M Davis
wrote:
On Saturday, October 19, 2013 18:50:16 Chris wrote:
A warning would be enough. The thing is I didn't want to give
it
the same name. It was meant to be the class variable but the
auto
was a leftover from a test. A warning would have been nice, à
la
"do you really want this?". I would have seen it immediately.
Warnings are pretty much always a bad idea IMHO. If you're
being a responsible
programmer, you fix all warnings, so they're ultimately not
really any different
from an error except that you can leave them alone temporarily
while
developing. It's far better to make something an error not have
the compiler
complain about it at all. lint-like tools can do additional
analysis based on
additional stuff that a programmer decides they want to look
for in their code,
but the compiler shouldn't be pointing out stuff that "might"
be wrong, because
you'll have to "fix" it whether it's wrong or not just to get
the compiler to
shut up about it.
And Walter agrees with me on this. Pretty much the only reason
that warnings
even exist in dmd is because he got pestered into adding them,
and even then,
we don't have very many. Most of them end up being warnings
about stuff that
will become errors later (rather than just making them an error
immediately
and break code).
- Jonathan M Davis
I can see your point. However, in this case a warning would
really make sense, in my opinion, because it is potentially
harmful and very likely not what the programmer intended, except
in a case like
this (string a) {
this.a = a;
}
which could be ignored by the compiler. Usually same-name
variables are only used in the constructor. Using them in other
places in the class is not recommendable, and I don't mind useful
warnings like "Listen, there is a variable shadowing the class
variable, do you really really want this?" To spam the command
line with compiler warnings is not very helpful, I agree, but is
it a good solution to categorically rule out warnings?
