Wish: Variable Not Used Warning

[Markus Koskimies]

On Wed, 09 Jul 2008 15:13:15 -0700, Davidson Corry wrote:

> 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.

This part I agree. D is a great language, and it has been my "home 
language" for years (replaced C++).

> I want a compiler that says *this* is legal D, *that* is
> not, and there's an end on it.

Maybe unused local vars, arguments or static arrays would be defined not 
to be legal D? :)
 
> 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_!

Oh, I would like to see that as a part of a compiler. In fact, the more 
the compiler generates warnings, the more I like it. For me, it could 
even warn about indentation quirks, like:

	...
	if(a == b)
		do_that();
		do_that_also();
	...

...In which case the compiler could stop and say, that either add {}'s or 
correct the indentation :)

> 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.

Ah, there needs only be one warning level - enable all, and regard 
warnings as errors. Who wants to disable warnings? Who want only see part 
of warnings? Just no use, IMO it's just OK to put all of them to screen 
and not to compile until the programmer has corrected those :)

> 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".

Heh, I like compilers that does not over-estimate the cleverness of the 
developer, but instead think that they (compilers) are the smarter 
part ;) Although being well known with syntax and best practices of a 
language, many times I write something else than I thought that I wrote. 
For catching these kind of spurious "miswritings", there are "syntactic 
salt" in many languages, including D. But at some point I think that it's 
no use to add more this salt, but instead do static checks to make the 
language better.

As a very simple example, the current DMD warns about this:

---
void error(string msg)
{
    writefln(msg);
    exit(-1);
}

int doSomethingWith(string a)
{
    if(a == null)
    {
        error("A null string");
    }
    else
    {
        return a.length;
    }
}
---
$ dmd test.d
warning - xxx: function test.doSomethingWith no return at end of function

...Since it does not understand that exit never returns (yes I know that 
that case should be written in different manner, but it is just an 
example). It could be told e.g. with some new return type (instead of 
"void exit" you would write "never_return exit"), and of course the 
analysis should go through the possible execution flows to check, which 
parts of the code may return and which parts cannot. Similar cases occur 
with switch statements.

What I try to say, is that IMO it is impossible to think that language, 
compiler (code generation) and static checking are three separate things. 
If there is a good synergy between these three elements, the language is 
great. But that's just my opinion...