Unused variables, better as error or warning?

[Jonathan M Davis]

On Friday, August 20, 2010 15:11:35 bearophile wrote:
> Jonathan M Davis:
> > The compile must be just as accurate when dealing with warnings as when
> > dealing with errors.
> 
> Nope. If your language (like C#) specs say that uninitialized variables are
> not allowed, the compiler has to catch them all and report them as errors.
> If your language (C, D, etc) allows you to not use a variable the last
> time you have initialized it, and then you want to add a warning that
> finds such situations, you don't need the compiler to be 100% accurate,
> even if some of such situations are not detected then it's perfectly OK.
> 
[snip]
> 
> > or have the compiler not complain when it couldn't be 100% certain. If an
> > algorithm could be devised which was 100% certain and the warning were
> > only given in such cases, then it would likely be acceptable.
> 
> In the meantime I have seen you have already commented on the bug report
> and I agree with with you write there. Thank you. For the In this specific
> case I think "zero false positives" is doable :-)

It's fine to have warnings which don't find all the instances of a problem, 
whereas errors _must_ find all of them. However, what isn't fine is having 
warnings give you false positives. The problem with Java or C# and 
initialization is that they're forced to give you false positives because it's 
an error to not initialize a local variable, and they can't let anything through 
that has _any_ possibility of not having been initialized. So, I'd argue that 
such features are either misfeatures (and the problem should be dealt with 
another way) or that it should be a warning. Ultimately, what should be avoided 
with regards to errors and warnings are

1. Errors where you have to deal with false positives because the compiler can't 
be 100% certain (D has generally dealt with this by doing stuff like default 
initialization or putting assert(0); at the end of a function rather than doing 
analysis which isn't 100% certain).

2. Warnings which you cannot get rid of or which force you to do something 
unreasonable to get rid of them.

Having extra warnings which warn you about stuff that the compiler knows is wrong 
but can't detect 100% of the time shouldn't be a problem as long as the 
programmer realizes that the compiler can't detect it all of the time.

- Jonathan M Davis