C++20 support by removing swap specialization

[gracicot]

[Describe your pull request here. Please read the text below the line, and make sure you follow the checklist.]

In C++20, the rule for customization point has changed.

From [namespace.std]/7:

Other than in namespace std or in a namespace within namespace std, a program may provide an overload for any library function template designated as a customization point, provided that (a) the overload's declaration depends on at least one user-defined type and (b) the overload meets the standard library requirements for the customization point.¹⁷³
[ Note: This permits a (qualified or unqualified) call to the customization point to invoke the most appropriate overload for the given arguments. — end note ]

This rule come from the paper P0551: Thou Shalt Not Specialize std Function Templates!

Swap is denoted as a customization point.

We can keep the specialization for older C++ version, but we should disable it for C++20 and above.

We also should provide a non-member swap function, ideally as a hidden friend.

This pull request implement those recommendations.

Please tell me if there's anything to fix or change in the patch.

---

Pull request checklist

Read the Contribution Guidelines for detailed information.

• Changes are described in the pull request, or an existing issue is referenced.
• The test suite compiles and runs without error.
• 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 file single_include/nlohmann/json.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 these kind of bugs). 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.

[coveralls]

Coverage remained the same at 100.0% when pulling 82fbbee on gracicot:cpp20-support-no-std-fct-templ-specialization into 7444c7f on nlohmann:develop.

[FrancoisChabot]

I think this is slightly misguided, C++20 is making overloading std::swap UB because it's a bad thing to do in general. This change is not just about satisfying C++20 for the sake of it, it's an objective improvement regardless of the standard version.

If moving away from std::swap to a proper ADL (which I am all for in general), then there is no particular reason to tie the transition to C++20. Users that are using the library today with C++11/14/17 still need to be notified somehow that the code they are in the process of writing is doomed.

[gracicot]

Overloading standard functions inside the std namespace was never allowed. Specialization of functions inside the std namespace was allowed before C++20. This is a new C++20 restriction.

Without ADL, the patch will make such code pick the default std::swap implementation with C++20.

Although if everyone agrees, I will gladly remove the specialization entirely for all language version and promote the hidden friend instead. You are right that this is an improvement for any versions.

[FrancoisChabot]

I was more thinking along the lines of adding a deprecation warning so that we can ease the transition, while grandfathering in existing codebases.

[jaredgrubb]

What would the deprecation say? Falling back to std::swap would probably work just fine right?

[gracicot]

@jaredgrubb exactly. No code written today will suddenly stop working. It's just that the default swap implementation will be picked instead, and might be slightly less efficient since it uses the move constructor instead of member-wise swap calls.

[nlohmann]

Looks good to me.

[nlohmann]

---

🔖 Release item

This issue/PR will be part of the next release of the library. This template helps preparing the release notes.

Type

• ✨ New Feature
• 🐛 Bug Fix
• ⚡️ Improvement
• 🔨 Further Change
• 🔥 Deprecated function

Description

• Remove swap specialization for C++20. C++20 support by removing swap specialization #2176

---