On Monday, May 07, 2012 23:56:40 Nick Sabalausky wrote:
> "Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.407.1336445190.24740.digitalmars-d@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

"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.408.1336451614.24740.digitalmars-d@puremagic.com...
>
> 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.
>

Ok, yea, I completely agree on all counts.

On Monday, 7 May 2012 at 23:25:56 UTC, bearophile wrote:
> So what do you think about having "-wi" (and even -property too) on default in D (and have a compiler switch to disable warnings on request)?

It sounds like a good idea to me, I'm all for it. The more warnings i get, the less probable i am to make wierd, subtle errors that are hard to track down.

On Tuesday, 8 May 2012 at 04:32:14 UTC, Jonathan M Davis wrote:
> ...
> 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).
> ...

If that's a problem, then why not add a parameter which says how many warnings to tolerate before treating them (all the errors up to this point) as an error, and make the default value for this parameter relatively strict? I'm sure i've seen this functionality in other compilers/tools.

/Pierre