Wish: Variable Not Used Warning

[Davidson Corry]

On Tue, 08 Jul 2008 14:40:26 -0700, Walter Bright  
<newshound1 at digitalmars.com> wrote:

> Nick Sabalausky wrote:
>> Ok, so the different warnings should be able to be turned on and off.  
>> If you don't agree with a particular type of warning then you turn it  
>> off. That's the nice thing about warnings as opposed to errors: they're  
>> optionally letting you know about certain conditions that you might  
>> want to be aware of, and they do it without changing, redefining, or  
>> otherwise affecting the language itself.
>
> That situation exists today for C++ compilers, and it's not so good. You  
> have, as I mentioned previously, n factorial different languages instead  
> of 1. Portability becomes a problem. Confusion about whether the code  
> should compile or not reigns.
>
>>> If it was in the compiler, it would inhibit development of static  
>>> analysis tools,
>> Can you elaborate on how this would happen?
>
> It's the same reason why "m4" never caught on as a C preprocessor,  
> despite being vastly superior, and despite everyone who wanted a better  
> CPP being told to use m4.
>
>
>>> and would confuse the issue of what was correct D code.
>>  Anything that generates a warning instead of an error is by definition  
>> valid code. If it wasn't valid it would generate an error instead of a  
>> warning.
>
> That's true, but it is not what happens in the real world with warnings.  
> I've dealt with warnings on C/C++ compilers for 25 years, and the  
> practice is very different from the theory.

I agree with Walter. One of the driving forces behind D was a desire *not*  
to have the quirks, corners and obscurities that grew within C++ over the  
years because Stroustrup wanted full backwards compatibility with C, etc.  
I want a compiler that says *this* is legal D, *that* is not, and there's  
an end on it.

I *also* want a tool (or sheaf of tools, smart editor, etc.) that will do  
lint-like static analysis and style vetting to warn me that, yes, this is  
legal D but you're using it in an obscure or unmaintainable or not easily  
extensible or not easily understood manner.  
_But_I_don't_want_that_tool_to_be_the_compiler_!

Walter is right that you end up with effectively 2**n different languages  
depending, not only on which warnings you enable|disable, but also on  
whether the shop you work for demands that you compile at /W1 or /W3 or  
/W4 and does or doesn't treat warnings as errors.

Yes, having the full parse tree available makes it easier to find some  
(not all) of those sorts of... not "errors", call them "infelicities". So  
compiler writers have tried to be generous and give their users more  
information "for free", and by doing so have made IMHO a design error. It  
is exactly analogous to overloading an operator with functionality that  
doesn't properly apply to that operation. You're trying to do too much  
with one tool.

I applaud Walter for not making that error. And I want him focused on  
writing a knife-clean compiler that stabs illegal code in the heart, and  
trusts the programmer to have meant what he said when the code is legal,  
even if it's "excessively clever".

Let someone *else* write "Clippy for D".

-- Dai