Wish: Variable Not Used Warning

[superdan]

Nick Sabalausky Wrote:

> "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.

group was given as an example. the thing is it has become clear to the luminaries that invoking better education is not an answer. it is clear from the literature and also from c++ oh ecs.

> > 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?

first i'd stop bitching why oh why the language does not build that shit in. that would be a great start. give me my fucking soapbox again. there. thanks. too many people around here are trigger happy about changing the language. (next breath they yell they want stability.) has nothing to do with you but reminds me of shit goin' on here in this group.

moron: "d has no bitfields. somehow in my fucking world bitfields are so essential, i can't fucking live without them. hence i can't use d. give me bitfields and i'll give you my girlfriend."

months go by.

walter: "here, there are perfectly functional bitfields in std.bitmanip. they're more flexible and more rigorously defined than in fucking c. you can count on'em."

moron: "don't like the syntax. still won't use d. i want them in the language. put them in the language and i'll use d."

> 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?

once i stop bitching i get a clearer mind and I get to write some shit like this.

void vacuouslyUse(T)(ref T x) {}

void foo()
{
    int crap;
    vacuouslyUse(crap);
    ................
}

use and remove as you wish. 

> 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.

unused name should be an error. if you want to not use something, you must sweat a little. vacuouslyUse fits the bill exactly. should be in phobos.

> 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.

it works but i kinda doubt you'll be all for it. you don't want to solve the unused variable problem. you want compiler warnings. somehow you'll work your argument out to make my solution undesirable.

> 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?

this is an imperfect world. i see value in the no warning stance. you don't see. therefore when competition in d compilers arena will pick up i'd see a warning as a shitty concession, while you will grin "i told ya all along".

> 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.

when doesn't it 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.

weak argument. a good program does some shit and does it well. i'm pissed that emacs can browse the web already, alright?