"Jonathan M Davis" <jmdavisp...@gmx.com> wrote in message news:mailman.407.1336445190.24740.digitalmar...@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 "$*"
