Am 27.11.18 um 22:01 schrieb Emil Dotchevski via Boost:
The problem is that implicit conversions happen a lot in C++ and it is wrong for the compiler to warn you about things you should know. By your logic this code should generate a warning:
short x;
++x;
Semantically, ++x contains an implicit conversion from int to short, which can result in loss of data. In this case I expect no warning. The initial conversion to int is a (strange) detail of C/C++. If I explicitly choose to operate on a short, why would I want an int? if "x" were an int, should it be promoted to a wider type on addition? If not, where is the consistency? So: Compiler can see *intend* here and not produce a warning. Same is true about signed/unsigned implicit conversions. Do you want a warning in this case?
unsigned x; int y;
x += y;
You're adding a signed int to an unsigned int, that seems so dangerous! You better cast, that would be so much safer. :) It is not about safer per se, it is about intend. If you cast explicitly you show intend (implying you checked the preconditions or have own assumptions on the value range in your domain), using the implicit cast *may* be a bug for all the compiler knows: "y = -(x+1)" -> Boom So it's all about: I know what I'm doing instead of I may know what I'm doing. To me it seems like a potential bug, introduced by a programmer who is unsure about implicit conversions in C. Semantically, I can't imagine why I would want the call to f to always cast to unsigned. Consider:
void f( unsigned ); void f( int ); //Later we add this overload
void g( int x ) { assert(x>=0); f(unsigned(x)); } Again: Intend. What if the (original) call to unsigned f is the correct one? Not using the cast now changes other, seemingly unrelated code just by adding a new function and may hence *introduce* a bug rather than avoid it.