Wish: Variable Not Used Warning

[Nick Sabalausky]

"superdan" <super at dan.org> wrote in message 
news:g53831$20jk$1 at digitalmars.com...
> Steven Schveighoffer Wrote:
>
>> "Walter Bright" wrote
>> > The reason for treating warnings as errors when warnings are enabled is 
>> > so
>> > that, for a long build, they don't scroll up and off your screen and go
>> > unnoticed.
>>
>> I've been following this thread, and I'm not really sure which side of 
>> the
>> issue I'm on, but this, sir, is one of the worst explanations for a 
>> feature.
>> Ever heard of 'less'?  or 'more' on Windows?  Maybe piping to a file? 
>> Maybe
>> using an IDE that stores all the warnings/errors for you?
>>
>> Please stop saving poor Mr. ignorant programmer from himself.  Education 
>> is
>> the key to solving this problem, not catering to the ignorance.
>>
>> Sorry for the harshness, but seriously!
>
> in c++ this kind of argument that contains "it's an issue of education and 
> shit" in it has been used for many years. after a lot of experience in the 
> field nowadays everyone silently agrees that that argument is useless. 
> folks on comp.lang.c++ start mocking you if u bring that argument up.
>

That's probably because over the past ten years, the people who care more 
about doing things the right way than catering to the status quo have been 
leaving C++ en masse (hence, D). It's no surprise that the people still 
remaining onboard C++ are either A. people who hold that particular 
viewpoint or B. people who are required to use C++ for some reason and have 
long since gotten used to the fact that C++ is never going to fix most of 
its problems. So I wouldn't place too much weight on the "comp.lang.c++" 
take on this particular issue; their consensus is likely just a reflection 
of group dynamics.

> i am 110% on walter's side on this shit. there should be no warnings and 
> shit. only errors. it is not catering to the ignorant. it is a matter of a 
> properly defined language.
>

That's right, no true warnings, but just a handful of what are in effect 
"optional errors".

In a "properly defined language", how would you solve the problem of 
unintentionally-unused variables?

Adopt the "unused" keyword that Koroskin Denis proposed and say that an 
unused var without the unused keyword is an error, and accessing a var that 
does have the unused keyword is also an error? That sounded good to me at 
first but then I realized: What happens when you're in the middle of an 
implementation and you stick the "unused" keyword on a variable in a 
function that you've only partially implemented just because you want to 
test the partial implementation. Then you fix any problems, get distracted 
by something else, and forget to finish (it happens more than you may 
think). Well great, now that wonderful compiles/errors dichotomy has just 
*created* a hole for that bug to slip in, whereas a real warning (the true 
kind, not the "warnings as errors" kind) would have caught it.

So how else could a "properly defined language" solve it? Just simply treat 
it as a non-error as it is now and be done with it? That turns 
potentially-noisy errors into silent errors which is one of the biggest 
design mistakes of all.

Any other suggestions on how to "properly design" a fix for that? If it 
works, I'd be all for it.

Suppose that does get fixed. Now, when some other common gotcha is 
discovered in a language, or a particular version of a language, that's had 
a design freeze (like D1), then what do you do? Stick to your "warnings are 
bad" guns and just leave everyone tripping over the gotcha in the dark, 
maybe hoping that someone else could come along and create a lint tool that 
would do the job that you could have already done?

Designing everything to fit into a compiles/errors dichotomy is great, in 
theory. But in practice it's just unrealistic. Even Walter ended up having 
to add a few "warnings" to D (even if he implemented them more as optional 
errors than as true warnings). Which is why, as I was saying in the 
beginning, trying to eliminate the need for a specific warning is great - 
*if* it actually pans out. But that doesn't always happen.

> a lint tool should not be folded into d. such a tool could e.g. follow 
> pointers, do virtual execution, and some other weird shit. it could run 
> for hours and produce output that takes an expert to interpret. that kind 
> of shit does not belong in the compiler.

Anything like that can be attached to an optional command-line parameter 
that defaults to "off". Problem solved.