About Go, D module naming

Jonathan M Davis jmdavisProg at gmx.com
Sat Dec 22 00:42:37 PST 2012


On Saturday, December 22, 2012 09:30:15 bearophile wrote:
> Jonathan M Davis:
> > but generally the worst that they'll do is create slight
> > overhead because of the cost of default initializing them.
> 
> I don't care about that overhead, because the optimizer stages of
> compilers take care of removing it in many cases, that's not one
> of the main points of spotting unused variables:
> - Removing unused variables makes the code tidier and more clean.
> - Unused variables are noise that makes harder to understand code
> and algorithms.
> - And most importantly, unused variables (or assigned and never
> read) are sometimes things that the programmers has forgotten to
> initialize or use, so they are sometimes associated with bugs.
> 
> > _especially_ if that means jumping through hoops to get
> > to not complain about legitimate unused variables.
> 
> Legitimate uses of unused variables are mostly in library code,
> or user code similar to library code. Adding to those variable
> definitions a @used is fast and perfectly easy. It's not a
> "jumping through hoops".

It requires extra work, making that code messier just because you want the 
compiler to help you point out places in your code where you failed to clean 
it up correctly by removing unused variables. You're basically asking for a 
feature to be added to the language so that the compiler will be able to tell 
you where your code is messy without complaining about legitimate code, _and_ 
your suggestion would make the legitimate code messier.

I really don't think that it's the compiler's job to tell you whether you have 
messy code or not. It's the compiler's job to tell you whether you have errors 
in your code or not. It's the job of a lint-like tool to find stuff like that.

And once we have a lexer and parser for D in the standard library (which I 
really need to get back to soon; life keeps getting in the way), creating 
lint-like tools will be much easier, and you can go mess around with one of 
those to get it to complain about every stray thing that you want your program 
to be examined for which isn't actually a question of whether the code is 
valid D or not. Let the compiler complain about code validity and leave the 
rest to other tools. Not to mention, if you work on such a tool, you have full 
control over whatever stray things it complains about, so you'll be free to 
get to complain about whatever you want without having to worry about 
convincing Walter Bright.

- Jonathan M Davis


More information about the Digitalmars-d mailing list