Re: [boost] Current Guidance on Compiler Warnings?

Subject: Re: [boost] Current Guidance on Compiler Warnings?
From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2018-11-26 08:12:29

Am 25.11.18 um 04:31 schrieb Emil Dotchevski via Boost:
> Here is my argument again:
>
> 1) A cast has different semantics than an implicit conversion.
>
> 2) If the implicit conversion is correct, replacing it with a cast to
> silence a warning is incorrect.
>
> Which of these two points do you think is false?

I'd argue both are false because they are to general.  If you add "may" 
then these arguments "may" be true.

I'll include your further reply:

> The reason is that they have the wrong mindset when approaching the problem.
> 
> They think: I get a warning, because the compiler doesn't know that this
> signed value is always positive, but I know that it is, so I'm going to
> cast, to tell the compiler that I know what I'm doing.
> 
> A better reasoning is: I'm converting a signed value to unsigned value,
> which will not be correct if the signed value is negative. With this in
> mind, you'll notice that the cast is utterly useless in catching the actual
> error the compiler is warning you about.

I can't really follow you here: The compiler not knowing that the signed 
value (which per definition CAN in general be negative) is always 
positive and alerting you of this is the whole point.
IF you know absolutely sure that this signed value is always 
non-negative, then why not:
a) Change the parameter type to unsigned to communicate this as a 
precondition of the function

b) add a cast to the unsigned parameter type and potentially an assert 
if this helps future readers and catch precondition violations

I don't see where this cast is wrong. It does the same as the implicit 
cast but explicit and hence conveys *intend*.

Disabling this warning might hide instances where such implicit 
conversions are in fact wrong.

I also see a contradiction in your argument: "this signed value is 
always positive, [...] I know that it is" is a valid reason to 
"converting a signed value to unsigned value, which will not be correct 
if the signed value is negative". So why is "the cast [...] utterly 
useless in catching the actual error"? If you know (or can ensure) the 
precondition then there is no error and you putting in the cast states 
that you thought about it.

Of course this is a should-be-world. If maintainers just throw in casts 
*without* checking that the cast is valid then it may be an error: 
Exactly the one the compiler was warning you about.

In conclusion: These warnings are about suspicious code that *needs* to 
be inspected. After inspection relevant action must be taken which 
should result in the warning being solved or suppressed so the next 
reviewer does not need to inspect it again unless surrounding code has 
changed.