-
-
Notifications
You must be signed in to change notification settings - Fork 6.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comparison of NaN differs between json and float #3409
Comments
Yeah, that's not quite right in the case of NAN. A special case is probably needed here for proper NAN handling:
|
One of them can also be integer or unsigned ( |
I see. But I guess fixing this would be a breaking change. 🤔 |
Yeah, it would have to include all the cases that include
That's unfortunate. |
What do you think of adding a policy macro to guard this fix. Something like |
If you really think a policy macro is required for this case, it's certainly better than fixing the issue in the next major release. I'd only suggest to at least default to the correct behavior and allow users to restore the old, broken behavior as needed. |
Last time I checked |
@t-b https://json.nlohmann.me/features/types/number_handling/#number-serialization
NaN is only converted to null when converting to text form, such as by the |
I'm currently working on implementing the spaceship operator. case value_t::number_float:
return (lhs.m_value.number_float) <=> (rhs.m_value.number_float); As I'm already inadvertently fixing this issue for some users, I'm inclined to fix the issue in it's entirety. Can we agree on a solution? Is a policy macro acceptable and which behavior should the policy macro enable? |
I am torn... On the one had, I do not want to have a breaking change. On the other hand, this is such an edge case that I begin to wonder whether anyone but @misos1 run into this. Furthermore, if the spaceship operator fixes this "accidentally", then this is one more argument that the current implementation is not just buggy, but surprising. |
To make sure we're on the same page:
|
* Add C++20 3-way comparison operator and fix broken comparisons Fixes #3207. Fixes #3409. * Fix iterators to meet (more) std::ranges requirements Fixes #3130. Related discussion: #3408 * Add note about CMake standard version selection to unit tests Document how CMake chooses which C++ standard version to use when building tests. * Update documentation * CI: add legacy discarded value comparison * Fix internal linkage errors when building a module
Description
https://json.nlohmann.me/api/basic_json/operator_le/
This means that
<=
always has the opposite result to>
even for NaN. Which gives weird results likejson(NAN) <= json(NAN)
is true butjson(NAN) < json(NAN)
is false whilejson(NAN) == json(NAN)
is also false #514.Reproduction steps
Expected vs. actual results
Actual:
Expected:
Minimal code example
No response
Error messages
No response
Compiler and operating system
clang
Library version
3.7.0
Validation
develop
branch is used.The text was updated successfully, but these errors were encountered: