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