Wish: Variable Not Used Warning

[Nick Sabalausky]

"Manfred_Nowak" <svv1999 at hotmail.com> wrote in message 
news:g51tmn$1kb3$1 at digitalmars.com...
> Nick Sabalausky wrote:
>
> > Like I've said, compiler warnings are essentialy a built-in lint
> > tool.
>
> Finally the contradiction seems to show up: if lint is a tool in its
> own right, then one must have strong arguments to incorporate it into
> any other tool.

1. There is no sufficient D lint tool either currently in existence or on 
the foreseeable horizon (at least as far as I'm aware).

2. The compiler is already in a position to provide such diagnostics (and in 
fact, already does for certain other conditions).

> In the paralell posting Walter remarks but not emphasizes that
> compilers have more goals, than enabling the evaluation of sources, on
> which your OP concentrates. Building large software systems and
> migrating some application source to another architecture are in the
> duties of compilers.
>
> For at least huge parts of these latter tasks a reevaluation of some
> static aspects of semantics of the application is useless but time
> consuming.

Hence, optional.

> In addition and by definition lint tools are not capable of
> doing more than this.

Which is part of what makes a compiler inherently more general-purpose, and 
a lint tool a mere symptom of a compiler's shortcomings.

> This is the central point: lint tools are only capable of informing
> about possible bugs. If a warning emitted by a lint tool would be a
> sure hint for a bug in the program, then the compiler should have
> emitted an error.

Warings are never sure hints about a bug in the program either. That's what 
makes them warnings.

> Thus there should be no need to incorporate any lint tool into any
> compiler. I am ready to read your counter arguments.

I could turn that around and say that with a sufficient lint tool 
incorporated into the compiler (activated optionally, of course), there 
would be no need for an external lint tool. Plus, an external lint tool is, 
by necessity, going to incorporate a lot of duplicated functionality from 
the compiler (roughly the whole front-end). Although I suppose that could be 
moved into a shared library to avoid duplicated maintenance efforts. But 
since you mentioned that having lint work being done in the compiler would 
be uselessly time consuming (Again, uselessly time consuming only if there's 
no switch to turn such checking on/off. Also, I assume you're referring to 
the speed of compiling), then I should point out that with an external lint 
tool, you're likely to have plenty of duplicated processing going on (lexing 
and parsing once for the external lint, and again for the real compiler).