DMD warnings

[Don Clugston]

Frank Benoit wrote:
> Don Clugston schrieb:
>> The problem is, those warnings are things that Walter thinks should not
>> be errors. More precisely, they are code constructs that are OK, 90% of
>> the time (at least, that's the case for narrowing conversions). We need
>> to more precisely capture the bad 10%, so that they can be turned into
>> errors. Here's a few things that could be done:
>>
> 
>> * The warning about "length" can become an error, now that we have "$".
>> * No return value really should be an error, except when the function
>> includes some inline asm. ...
>> * Maybe something for the default in switch statements, too.
>> * Narrowing conversions are a big problem. 
> 
> The only way to capture the bad 10% is to fix all. Thats my point,
> nobody should ignore warnings, because this bad 10%.

The ideal compiler would generate error messages for everything that's a 
bug, and not for anything else. Warnings (or errors) are only useful if 
they indicate that that line of code is significantly more likely (say 
100 times) to contain a bug, than any line which does not generate any 
warnings.

Example: a missing return statement definitely falls into this category. 
But in my experience, I don't think I have ever seen a single 
signed/unsigned mismatch that was a bug -- but I've seen that warning in 
C++ thousands upon thousands of times.

> So lets force them to be errors with a back door for emergency.
> 
>>> pragma( nowarn, 234 ){
>>>     // code generating the warning 234
>>> }
>>>
>>> So it is documented in the code. This is nice.
>> But it looks horrible, and it's only purpose is to turn off the warning.
> 
> Yes it looks horrible and it shows a horrible situation. It was not
> possible to fix a warning.
> This should be used rarely. Instead fix warnings:
> Missing cast => add one
> Missing return => add a return, assert(false) or throw
> ...
> 
> int i =3;
> uint s = cast(uint)i;
> 
> I really think it is better style to have this explicite cast in the
> code. Because a reader can see, it is not only an assignment, there is
> also a cast which can have side effects.

The problem is, that is *not* what a cast says! Suppose you change the 
definition of i to be:
double i = sin(56);
Now, the line about s will compile without warnings. Adding the cast has 
  removed the warning, but it has also cluttered the code and introduced 
a latent bug. You also won't be able to use a lint tool (or even -w) to 
find the problem. Casts are evil. Thousands of time more evil than 
changing from signed to unsigned.

> If you ignore warnings you will not be aware of this, if you read this
> code in half a year.
> 
> But perhaps there is a situation you cannot fix the warning or don't
> want to change the code in this way. So you have this back door.
> 
>> Warnings are indications of problems in the language semantics -- it
>> means the compiler doesn't have enough information to determine if the
>> construct is erroneous or not. The solution is definitely not to make
>> the construct always an error.
> 
> Sure! It is easy to provide the information to the compiler. Add the
> cast, return, ...
> This process is valueable because you notice an error, decide to fix the
> warning or decide to switch this warning off for the certain sequence.
> 
> So treating warnings as errors, forces the user to think about. And that
> is the sense of warnings.

Yes, but *only* if the warning is removed in a way that results in less 
ambiguous, less buggy code. Right now, we don't have language mechanisms 
that do that for all the cases that currently produce warnings. 
Hopefully they will come eventually.