Change `operator==` overload that constrains to `is_scalar_v` to constrain to compatible types.

[fsandhei]

https://github.com/nlohmann/json/issues/4165 shows an issue with the overload resolution when attempting to compare a std::string with json from left to right. This can be fixed by changing the constraint to instead of focusing on scalar types, we constrain the comparison operator to "compatible types", in par with the catch-call constructor.

Pull request checklist

Read the Contribution Guidelines for detailed information.

• [x] Changes are described in the pull request, or an existing issue is referenced.
• [x] The test suite compiles and runs without error.
• [x] Code coverage is 100%. Test cases can be added by editing the test suite.
• [ ] The source code is amalgamated; that is, after making changes to the sources in the include/nlohmann directory, run make amalgamate to create the single-header files single_include/nlohmann/json.hpp and single_include/nlohmann/json_fwd.hpp. The whole process is described here.

Please don't

• The C++11 support varies between different compilers and versions. Please note the list of supported compilers. Some compilers like GCC 4.7 (and earlier), Clang 3.3 (and earlier), or Microsoft Visual Studio 13.0 and earlier are known not to work due to missing or incomplete C++11 support. Please refrain from proposing changes that work around these compiler's limitations with #ifdefs or other means.
• Specifically, I am aware of compilation problems with Microsoft Visual Studio (there even is an issue label for this kind of bug). I understand that even in 2016, complete C++11 support isn't there yet. But please also understand that I do not want to drop features or uglify the code just to make Microsoft's sub-standard compiler happy. The past has shown that there are ways to express the functionality such that the code compiles with the most recent MSVC - unfortunately, this is not the main objective of the project.
• Please refrain from proposing changes that would break JSON conformance. If you propose a conformant extension of JSON to be supported by the library, please motivate this extension.
• Please do not open pull requests that address multiple issues.

[github-actions[bot]]

🔴 Amalgamation check failed! 🔴

The source code has not been amalgamated. @fsandhei Please read and follow the Contribution Guidelines.

[github-actions[bot]]

🔴 Amalgamation check failed! 🔴

The source code has not been amalgamated. @fsandhei Please read and follow the Contribution Guidelines.

[coveralls]

coverage: 100.0%. remained the same when pulling 65b9b38ff33829b43d15488d84413233a34d63fb on fsandhei:fix/equality-operator-for-compatible-types into 0457de21cffb298c22b629e538036bfeb96130b7 on nlohmann:develop.

[nlohmann]

Can you please try to amalgamate with an older version of astyle, like astyle 3.2? There was a breaking change in astyle which makes the output differ unfortunately.

[fsandhei]

Can you please try to amalgamate with an older version of astyle, like astyle 3.2? There was a breaking change in astyle which makes the output differ unfortunately.

Sure, I'll do it some time later today after work.

[fsandhei]

First, sorry, @nlohmann, for the trouble I'm causing here.

So, I tried amalgamating again. There seems to be some issues or inconsistencies with the astyle version 3.2.1 from the AUR versus 3.2.1-build from apt:

• --squeeze-lines is not defined in the one from Arch, so I had to comment that one out in order to make the amalgamate step run.
• As far as I see, squeeze-line was introduced in 3.3.x.
• A bunch of files are affected by the amalgamate, which does not seem right.

Would you want me to perhaps unstage all the other unrelated files that got affected by this?

[github-actions[bot]]

🔴 Amalgamation check failed! 🔴

The source code has not been amalgamated. @fsandhei Please read and follow the Contribution Guidelines.

[nlohmann]

This is what I am using locally (patched Makefile):

# call the Artistic Style pretty printer on all source files
pretty:
	/Users/niels/Downloads/astyle/build/astyle \
	    --style=allman \
	    --indent=spaces=4 \
	    --indent-modifiers \
	    --indent-switches \
	    --indent-preproc-block \
	    --indent-preproc-define \
	    --indent-col1-comments \
	    --pad-oper \
	    --pad-header \
	    --align-pointer=type \
	    --align-reference=type \
	    --add-braces \
	    --convert-tabs \
	    --close-templates \
	    --lineend=linux \
	    --preserve-date \
	    --suffix=none \
	    --formatted \
	   $(SRCS) $(TESTS_SRCS) $(AMALGAMATED_FILE) $(AMALGAMATED_FWD_FILE) docs/examples/*.cpp

with Astyle 3.1.

[fsandhei]

Thank you for so quick response. The amalgamation seems happy now.

[nlohmann]

Thank you for so quick response. The amalgamation seems happy now.

Thanks for your effort!

[fsandhei]

I see that the GCC 10 CI run failed. It seems to be not able to parse the concept, which is odd as it should be supported in GCC 10.

For the sake of getting this in and have the least amount of hassle I don't use concept.

However I was pondering on the idea of having a concept which could replace these type traits definitions for recognizing "compatible types". I tinkered with this simple concept below. It worked perfectly fine. I don't know if it is missing any details, though. Would appreciate hearing your opinion on this, as I'm far from an expert :)

#ifdef JSON_HAS_CPP_20
   #include <concepts>
    template <typename T, typename BasicJsonType, typename U = uncvref_t<T>>
    concept CompatibleType = requires(const U& type, BasicJsonType& j) {
        { to_json(j, type) } -> std::convertible_to<void>;
    };
#endif

The use of this would be quite simple, as we'd then can constrict constructors / operators with this concept:

template <CompatibleType<basic_json_t> T>
operator==(T rhs) const noexcept
{
   ...
}

EDIT: I realize I goofed myself. It is supported but JSON_HAS_CPP_20 is not defined because g++10 requires -std=c++2a. I'm able to get past this by also checking for __cpp_concepts to be defined at where we define the concept.

[fsandhei]

I'm not really sure what is Codacy is actually complaining about. The struct member is being used in the type trait. It might be a bug in Codacy. Do you have any suggestions @nlohmann?

[nlohmann]

I'm not really sure what is Codacy is actually complaining about. The struct member is being used in the type trait. It might be a bug in Codacy. Do you have any suggestions @nlohmann?

Indeed looks like a false positive. I set it to "ignore".

[github-actions[bot]]

🔴 Amalgamation check failed! 🔴

The source code has not been amalgamated. @fsandhei Please read and follow the Contribution Guidelines.