-wi on default?

[Jonathan M Davis]

On Monday, May 07, 2012 23:56:40 Nick Sabalausky wrote:
> "Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message
> news:mailman.407.1336445190.24740.digitalmars-d at puremagic.com...
> 
> > On Tuesday, May 08, 2012 04:21:06 bearophile wrote:
> >> Jonathan M Davis:
> >> > A good programmer will never leave _any_ warnings in committed
> >> > code.
> >> 
> >> Sometimes warnings are wrong, the compiler is not perfect.
> >> If the compiler is certain there is a mistake in the code, then
> >> generating an error is better. Bugs are probabilistic.
> >> Good lints don't have just "errors", they report issues
> >> classified in four or five levels of increasingly probability of
> >> actual problem being present (naming them something like "Info",
> >> "Note", "Warning", "Probable Error", and "Error").
> > 
> > If it's not something that _must_ be fixed, the compiler should _not_
> > complain
> > about it precisely because you should _never_ leave any warnings in
> > committed
> > code. Leaving warnings in committed code (even if invalid) leads to valid
> > warnings being missed and/or ignored, which leads to bugs being uncaught.
> > If a
> > compiler restricts itself to stuff which is _definitively_ wrong, then
> > that
> > isn't a problem. A compiler is _not_ a lint tool and shouldn't be treated
> > as
> > one.
> 
> A compiler isn't a profilier, documentation generator or unittesting tool
> either, but a big part of D's philosophy is that there *is* real value in
> having such things in the compiler anyway. The more significant warnings
> should normally be on (ie, stuff that's ok while debuggng, but shouldn't be
> checked in), but lint-style pedantic analysis likely *shouldn't* be enabled
> on every build anyway, so the "stuff getting ignored" argument doesn't
> really apply.
> 
> And as I said some time ago, if you still *really* want a line tool to be
> separate from the compiler for whatever "purity" or ideological reason,
> that'd be easy enough to do:
> 
> $cat dlint
> #!/bin/bash
> dmd -lint "$*"
> #or
> dmd -pedantic-warnings "$*"

I think that it makes sense to have flags for enabling certain types of 
warnings. The programmer can then choose to enable warnings for the things 
that that they want to warn about (be it on all builds or just on a build 
which is intended to check for the type of stuff that lint checks for). What I 
do _not_ want to see is for such warnings to be part of -wi or -w.

I'm _very_ much against having normal warnings which are things which don't 
definitively need to be fixed, because otherwise you get into the situation 
where people ignore them, and the quality of the software suffers, because you 
get a ton of warnings that don't get fixed, some of which _need_ to get fixed 
and others which just hide those warnings by helping to make the number of 
warnings too many to examine. Optional flags for additional warnings don't 
introduce quite the same problem (though obviously if you always insist on 
them for your builds, you risk the same problems as if they were part of -wi).

However, as I understand it, Walter is against having a bunch of different flags 
for enabling or disabling different warnings, so it's unlikely that we're going 
to get that with dmd, regardless of whether it would be an improvement or not.

- Jonathan M Davis