On 22/11/2018 14:49, Emil Dotchevski wrote:
First, any change in a correct program can introduce a new bug. Secondly, "fixing" a warning often alters the semantics of the operation in a subtle way. Consider for example the use of an explicit cast to silence a warning that an implicit conversion may lead to something bad. You may think that all you've done is silence the warning, but in fact you've changed the program semantically: it no longer does an implicit type conversion, instead it does an explicit one. And the thing is, one of the two is incorrect.
Now, if your programmers don't understand how implicit type conversions work in C++, it is possible that enforcing warning-free compilation avoids more bugs than it causes. If that's the case, there's no argument.
Perhaps I am one of these programmers who don't understand how implicit type conversions work (although I don't believe so), but... Where implicit conversions are permitted, there is no difference in actual compiled behaviour at the call site between an implicit and explicit conversion. At all. They are utterly identical. There *is* a difference in the warnings, because the compiler will emit warnings "hey, this can do unintended things sometimes, did you really want to do that?" for the implicit case and not for the explicit case, because for the latter it assumes you know what you're doing. There *is* also a difference at the target site (the class implementing the conversion) and its choice of whether it should allow or prevent implicit conversions (and as is typical of C++'s defaults being wrong most of the time, it is usually wrong to allow implicit conversions -- though not always). (And getting that wrong can cause unintended implicit conversions, but those usually present themselves differently from the warnings we're talking about here.) What is also true is that it is a bad idea to get into the habit of seeing such a warning and "I know, I'll fix it with an explicit cast" without looking closely at the code -- because *in some cases* this ends up concealing a genuine bug in the code which the compiler was trying to helpfully warn you about (such as potential for integer overflow or narrowing). Ensuring that code compiles without warnings is very helpful, to make it easier to spot when new warnings crop up and need to be examined. *But* you do have to be disciplined and analyse and test (preferably with input fuzzing) the code where the warnings appear, not just blindly (and sometimes incorrectly) putting in a cast to make the compiler shut up. The compiler doesn't just issue warnings on any implicit conversions, only on those that seem potentially unsafe. So you should not be ignoring these, you should be fixing them. Sometimes that means making an explicit conversion instead. Sometimes that means changing types or verifying input sanity. Sometimes something else. But it shouldn't be left producing warnings when it can be (properly) fixed.