"div0" <[email protected]> wrote in message news:[email protected]... > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Nick Sabalausky wrote: >> >> Sounds like a good time to nag again about the idea of a "treat warnings >> as >> warnings" option: >> >> http://d.puremagic.com/issues/show_bug.cgi?id=2567 >> >> A patch is even there that adds "-ww" as an alternative to "-w" that >> enables >> warnings, but actually treats them as warnings. I *really* hate that DMD >> doesn't currently offer an ability to enable warnings without treating >> them >> as errors, because the current way amounts to nothing more than "optional >> errors", which effectively splits D into two different languages (and >> those >> two languages are a slightly less helpful one, and a somewhat naggy one, >> but >> the option to treat warnings as warnings would merge them back into the >> same >> language while maintaining the best of both). >> >> > > NO. NO. NO. NO! NO. NO. NO. NO! NO. NO. NO. NO! NO. NO. NO. NO! > > N N NNN NNN > NN N N N NNN > N N N N N NNN > N NN N N > N N NNN N > > That is an amazingly shit idea. > Have you *ever* tried to write portable c++ code??? > > It's utterly impossible without prefixing and postfixing *every* single > header filer with the following shit: > > [more stuff involving how much of a pain warnings can be on C/C++]
Ok, great. Now take the way C/C++ is with warnings right now, as you've described, then change it so that *all* C/C++ warnings are *always* treated as errors, and tell me how in the world that doesn't make the situation *even worse*, let alone somehow better. The only difference would be that if a warning gets through, instead of being a mere potential annoyance to the client, you'll have broken their whole damn build. Wonderful! How could that possibly be an improvement? Besides, I've been starting to wonder if the *real* problem isn't that warning settings always get propogated to libraries (instead of being settable on a package-by-package basis. For instance, why shouldn't a programmer be able to tell the compiler "I want these warning settings for this app I'm compiling, but to hell with any potential warnings in xx and yy libraries because that ain't my damn code so don't bug me with it right now!"?). I'd think that would fix all those problems with warnings that you've described, at least for the most part. Of course, that probably can't be fixed in C++ (but then, what *can* be fixed in C++? ;) ), but D actually has a module system which should make it possible, at least in theory. As far as warnings belonging in a separate lint tool...well, show me a D lint tool that, at a minimum, handles the warnings DMD emits, and preferably doesn't require the whole f*cking parse process to be repeated, and I'd be perfectly happy having all warnings ripped out of my compiler. But there is no such D lint tool, in fact, there ain't no D lint tool at all! So until that actually gets made, what we have is warnings, and as I've said above, having optional non-fatal warnings, bad it it might potentially be, is a hell of a lot better than forcing all the warnings to be toggleable errors.
