Rationale for treating double as distinct in comparisons?

[ecorm]

Rationale for treating double as distinct in comparisons?

[ecorm]

A corner case where the Boost.Json comparison behavior could be problematic is when a Javascript peer accidentally serializes a semantically floating point value into an integer without a decimal point, because the number just happens to be one that's exactly representable as an integer.

{"voltage": 3.10104} -> document.at("voltage") == 3.0 -> false // OK

{"voltage": 3.0} -> document.at("voltage") == 3.0 -> true // OK

{"voltage": 3} -> document.at("voltage") == 3.0 -> false // Oops

Where "voltage" is a fluctuating value that could coincidentally be exactly 3 (e.g. a 12-bit analog-to-digital converter).

[ecorm]

I just realized in my example above that nobody should do such a floating-point equality comparsion without a +/-epsilon.

[ecorm]

I guess a good rationale for treating signed/unsigned integers as the same kind in comparisons is when using literals on the right hand side:

{"id": 42} -> 42 parsed as unsigned integer
document.at("id") == 42 // Literal 42 is signed!

[grisumbras]

The rationale is that the stored values are different and thus certain member functions would have different behaviours. It would be strange to have equal values behave differently.

If the user wants a more lax comparison, it can be acheived: https://godbolt.org/z/4vz9h63MG. If you can use C++ concepts, than here is a slightly cleaner version: https://godbolt.org/z/TahMGMG8o.

BTW, 42 would parse as int64_t. And "42" would parse as json::string.

[ecorm]

The rationale is that the stored values are different and thus certain member functions would have different behaviours.

But int64_t and uint64_t are stored differently, yet they are treated as the same kind in comparisons. This does not adequately explain why double is treated as a different kind in comparisons.

It would be strange to have equal values behave differently.

It is currently "strange" that assert(json::value(42) == json::value(42.0) fails.

BTW, 42 would parse as int64_t. And "42" would parse as json::string.

I incorrectly assumed 42 would parse as uint64_t because that's what the current JSON library I'm using does (only negative integers get parsed as int64_t). The quoted "42" in my example was a brain fart. :-)

[grisumbras]

But int64_t and uint64_t are stored differently, yet they are treated as the same kind in comparisons. This does not adequately explain why double is treated as a different kind in comparisons.

You got me there. I guess, it's for the convenience of value(1u) == 1.

[ecorm]

BTW, 42 would parse as int64_t. And "42" would parse as json::string.

I incorrectly assumed 42 would parse as uint64_t because that's what the current JSON library I'm using does (only negative integers get parsed as int64_t). The quoted "42" in my example was a brain fart. :-)

Ah, I think I've stumbled upon the rationale right there. Treating signed/unsigned integers as the same kind in comparisons eliminates the guesswork and messiness in dealing with how the library parses positive/negative integers into uint64_t or int64_t.