Detector for unused variables

[Regan Heath]

On Wed, 01 Aug 2012 11:38:46 +0100, bearophile <bearophileHUGS at lycos.com>  
wrote:

> Regan Heath:
>
>> Indeed.  IIRC Walter's rationale on things like this has always been  
>> that they belong in 3rd party tools.
>
> Walter is not always right.

Well, in this case I agree with him.  You're not looking at the big  
picture.  If you make detecting un-used variables a /requirement/ for  
implementing a D compiler, you make it that much less likely someone will  
write one, which raises the bar for D's adoption.  The reason why there  
are so few good C++ compilers is that the language is too hard to  
implement, we don't want D to go that way.

>> It's why the DMD front end is available for use, so people can create  
>> tools like this, syntax highlighters, re-formatters, dependency tree  
>> diagrams, or... you name it.
>
> Detecting unused variables is a core feature, it belongs in the compiler

Says you.  I disagree.  We may have gotten used to it being there, but  
it's not part of the "compilation" phase but rather part of the  
"development" phase and/or the "quality control" phase which are arguably  
the realm of the IDE or a "lint" checker.

> like compile-time array bound tests and other errors currently detected  
> by DMD.

The key word used here is "error". Unused variables do not affect the  
compilation of a program, they're simply ignored and have no effect.   
Array bounds errors will crash the program.

> This allows everyone to use it with minimum work, so everyone enjoys it,  
> and it requires less work to be implemented because the compiler already  
> does lot of analysis.

Sure, but everyone is not the bottleneck, Walter is.  The work to  
implement it has to be done by someone, somewhere.  If we make it a  
requirement for a D compiler then every D compiler writer has to do it,  
including Walter and as a result all D compilers will be that much worse  
for the wasted time/energy used to implement it, not to mention fix any  
bugs that arise - as they will be very visible - despite being almost  
irrelevant to the main purpose of the "compiler".

If it's done by a 3rd party tool it will be done better - as more time can  
be spent on it, as it's a main feature of said tool, etc.

In short, it's better for everyone if it's done in a 3rd party tool.   
Further, that tool could be fully integrated, i.e. distributed by/with the  
compiler and run as a pre or post compile step automatically such that to  
users it's indistinguishable whether the compiler or the tool is doing the  
work.

All we need is someone to produce and maintain the tool, and for Walter to  
add it to the distribution and hook it into the compiler.  Then, we can  
have competing tools, and competition breeds improvement..

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/