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.