Unused variables, better as error or warning?

[Jonathan M Davis]

On Friday, August 20, 2010 14:06:49 bearophile wrote:
> Jonathan M Davis:
> 
> I have seen you have commented in the enhancement request too, thank you
> for your answers.
> 
> >I agree with #1, #3, and #4 but not #2. It requires control flow analysis
> >to get that to work, and Walter generally avoids that.<
> 
> The situation here is different.
> 
> Walter was opposed to forcing initialization of variables and then using
> flow analysis to spot all cases where the program isn't doing this. Walter
> has said that some cases can't be determined (and probably also to keep
> compler simpler and faster) has refused to do this (that the C# compiler
> does).
> 
> But what I am discussing there is not a change in the language, it's a
> diagnostic thing. A conformant D compiler is free to give or not give
> warning for unused variables (or variables unused after the last
> assignment. This is a different warning).
> 
> This means that it's OK in this case for the compiler to not perform an
> accurate analysis, because even if it misses some cases it's OK still. So
> it's a very different situation.

The compile must be just as accurate when dealing with warnings as when dealing 
with errors. The reason is that any good project is not going to have _any_ 
warnings in it when it's done. And forcing the programmer to do extra, pointless 
stuff just to get rid of them is not good. Java and C# make you do that in 
various places with variable initialization because they do code flow analysis 
for variable rather than default initialize variables. Because D default 
initialiazes everething, that sort of code flow analysis becomes unnecessary.

For something to be a warning, it has to something that must reasonably be fixed 
in a program before it's done but can be temporarily ignored. Having the 
compiler do code flow analysis (which it _can't_ do perfectly due to a lack of 
information) to determine something is going to result in cases where the 
program is forced to do something unnecessary just to get rid of the warning. 
So, in order for such a warning to be put in the language, it has to be worth 
that extra cost.

> >In more complex cases, the compiler is not going to be able to accurately
> >detect when something is or isn't going to be assigned to in ever code
> >path, so you'd be forced to initialize it in spite of the fact that it's
> >default initialized.<
> 
> I think we are talking about two different things.
> 
> The "unused last assignment" warning means that you assign something to a
> variable, and then you do nothing with it. So you have wasted efforts, and
> that is code smell of sloppy or code where you have forgotten to use the
> variable.
> 
> This has nothing to do with uninitialized variables, it's kind of the
> opposite problem. Sorry for lumping two different warnings into the same
> enhancement request.

Your example for this exact problem involved a default-initialized variable 
rather than double-assignment, so if you didn't intend to lump default-
initialized variables in with double-assigned variables, it was a poor example.

Regardless, the same type of code flow analysis applies. So, for it to be worth 
making a warning, it has to be worth whatever pain comes with the compiler 
getting it wrong. And in this case, that means that either you'd have to _not_ 
assign to something when you're supposed to (which would obviousy be very bad), 
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. However, since Walter 
has generally tried to avoid all such code flow analysis (IIRC mainly because it 
complicates the compiler and makes it more likely that it's wrong), I wouldn't 
expect it to ever make it into the compiler.

- Jonathan M Davis