5 ms·
Are you saying that it is intuitive that 4/2 should return a floating point number? Or the type of the result should depend on the value? I would expect that n
by gpderetta 2y ago
Are you saying that it is intuitive that 4/2 should return a floating point number? Or the type of the result should depend on the value?
I would expect that no C or C++ programmer would find it intuitive
- tialaramex 2y ago> I would expect that no C or C++ programmer would find it intuitive My guess is that if instead C and C++ had two operators here you'd find C and C++ programmers fiercely defending this reality as the only correct choice. The tribalism particularly in C++ is very strong. There are a handful of accepted topics for disparagement, such as the std::vector<bool> specialisation but outside that any questioning of orthodoxy is not well tolerated.
- gpderetta 2y agoAside from the flame-baity strawman, I'm not sure for which behaviour you are exactly arguing for.
- tialaramex 2y agoThere are several attractive options, any of them eliminates this kind of bug 1. Giving the integer and floating point division operations different operators. If we designate // as specifically the integer division operation then this bug never arises. 2. Don't have untyped constants. If the old constant had been a floating point type, the erroneous change jumps out because we're obliged to write that we now want an integer type. Unfortunately the pre-processor is just text mangling, so this constant had no type as far as C is concerned. Odin is uncommon in modern languages for having untyped constants, Ginger Bill can probably explain why he thought that's a good idea but I can't defend it. 3. Forbid coercion/ promotion of numeric types (perhaps as part of forbidding silent type conversions in general) so now the original expression won't compile anyway.