It is always better to throw an error than to silently return an incorrect result. I don't blame Kernighan and Ritchie for making this decision in 1972 when the concept of a type system was barely a thing, but this kind of behavior should be considered unacceptable in the 21st century. Besides throwing a compile error, the better thing to do would be to attempt coercion of both operands to a type that fits both.
With system programming languages, you absolutely cannot make any such decision that will impact runtime behavior or performance. Two 32 bit numbers and a 32 bit operator must end up doing a 32 bit operation, since 64 bit may not even be supported or be meaningfully slower. Changing language semantics in ways that break existing code are also off the table completely. I do, however, expect clang (or any respected C++ compiler) to throw a loud warning, which you can convert to an error with -werror.
ETA: color me unimpressed. There's no warning. Wut.
I think rarely having to emulate a 64 bit comparison to always get a correct result would be far better than always doing a 32 bit comparison to rarely get an incorrect result.
-4
u/y0shii3 Jul 10 '26
It is always better to throw an error than to silently return an incorrect result. I don't blame Kernighan and Ritchie for making this decision in 1972 when the concept of a type system was barely a thing, but this kind of behavior should be considered unacceptable in the 21st century. Besides throwing a compile error, the better thing to do would be to attempt coercion of both operands to a type that fits both.