Tips from the compiler

[Nick Sabalausky]

"Don" <nospam at nospam.com> wrote in message 
news:i9ic4k$eh4$1 at digitalmars.com...
> Nick Sabalausky wrote:
>> "Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message 
>> news:mailman.693.1287403175.858.digitalmars-d at puremagic.com...
>>> I, for one, want the compiler to tell you about things that are either
>>> absolutely guaranteed to be a problem or things which are _highly_ 
>>> likely to be
>>> a problem. Anything less that doesn't belong in the compiler IMHO. If 
>>> it's in
>>> the compiler, then it's going to be bugging me every time that I 
>>> compile.
>>
>> There are these things called "command line options", maybe you've heard 
>> of them?
>
> Maybe you've not heard of what a problem they are in C++? Ever had to turn 
> individual warnings on and off just to get some different libraries to 
> compile?
>
> The problem is, once you have an "optional warning" in a compiler, they 
> are NOT optional. All standard or pseudo-standard libraries MUST comply 
> with them.
> And if you have an idiotic warning that keeps complaining about perfectly 
> valid code (VC++ for example has many such warnings), what you've done is 
> reduce the quality of everyone's code everywhere.
> IMHO, it's extremely unprofessional for the compiler to cry wolf all the 
> time, rather than to clearly identify the symptoms of genuine bugs.

See my earlier post on warning levels. There's no reason for library 
compliance, even on a std lib, to be mandatory on "B" and "C" types. And std 
lib compliance on "A" types isn't problematic.