Regarding compiler switches

[Nick Sabalausky]

"div0" <div0 at users.sourceforge.net> wrote in message 
news:hcvnfd$pmq$1 at digitalmars.com...
> -----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.