|Posted by Jonathan M Davis|
in reply to bearophile
Posted in reply to bearophile
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