Int and uint compare equal but hashes do not

Description

On the implementation of std::hash, the C++ specification states:

If k1 == k2 is true, h(k1) == h(k2) is also true

Yet this is not the case for json values of the same numeric value but of signed and unsigned storage types. I can see this behaviour is documented here, but it violates the std::hash contract. While this behaviour is great for distinguishing between the other types, it feels unnatural for it to distinguish between signed and unsigned types.

Reproduction steps

using namespace nlohmann;

int main()
{
    const json a{42};
    const json b{42u};

    assert(a == b);
    assert(std::hash<json>{}(a) == std::hash<json>{}(b));
}

Expected vs. actual results

I would expect assert(std::hash<json>{}(a) == std::hash<json>{}(b)); to succeed because a == b is true, but it actually fails.

I believe the hash<basic_json> implementation should treat signed and unsigned integers the same. This is especially important because the storage type selected by the parser is not specified (currently, see #5255 ).

In all other aspects, signed and unsigned integers are treated the same: there is no distinction made in the JSON standard and they are silently cast between when calling .at() or .get<>().

Minimal code example

// I'd like to be able to write code like this

using namespace nlohmann;

int main()
{
    const json j = R"({"a": 42})"_json;
    const std::unordered_map<json, std::string> m = {{42, "hello"}};
    std::cout << m.at(j.at("a")) << '\n'; // throws std::out_of_range
}

Error messages

Compiler and operating system

GCC 12.2.0, Linux

Library version

3.12.0

Validation

• The bug also occurs if the latest version from the develop branch is used.
• I can successfully compile and run the unit tests.

Start at the hash<basic_json> implementation and reproduce the issue with the signed and unsigned 42 examples from the report. Review the linked pull request, then run the relevant unit tests; done means equal json values produce equal hashes and the unordered_map lookup succeeds.