Reference tuple from json

[EALePain]

The current std::tuple from_json implementations fail to work with std::tie, aka tuples with reference types. The reason for this is that the template types are maintained all the way to the call to get<Args>() resulting in things like get<int&>(). The PR modifies this behavior to remove the references from all incoming types if those references are incompatible with the json type being used.

Ultimately this change allows for the result of std::tie to be used with get_to and allows the get method to create std::tuples of references to contained values.

The specific set of changes needed to achieve this are:

1. The addition of the is_compatible_reference_type metaprogramming struct that contains ::value = true if the BasicJsonType given has a get_ref instantiation that accepts CompatibleReferenceType (I used get_ptr because SFINAE was not working correctly with get_ref). This allows for overload resolution to decide to use get (and decay the type) or get_ref if a reference type is available for the individual elements of the tuple.
2. The addition of the meta/logic.hpp header adding cxpr_or, cxpr_and, and cxpr_not that allow for c++ 17 fold expressions for || and && (with not for semantic consistency) in version older than 17. This is needed for the static assert (which I discuss later)
3. The addition of the from_json_tuple_get_impl overload set. In reverse priority order they:
   1. decay all types to values and calls get<T> on the json, returning by value
   2. if a type is a compatible reference type, calls get_ref and returns exactly the type given.
   3. if a type is an arethmetic type, call get and return by value. This one specifically exists to allow std::ties containing number_xxx_t to not fail when the type is some other number type.
4. a template using statement tuple_type that figures out the return type of a call to from_json_tuple_get_impl so that a tuple of exactly the correct types can be constructed from calls to it.
5. modifications to from_json_tuple_impl_base implementations adding a priority tag value template argument (to circumvent the from_json_tuple_get_impl(..., priority_tag<2>) implementation for calls to get references to members) and to return tuple_type and use from_json_tuple_get_impl.
6. add a static assert to from_json_tuple_impl(..., identity_tag<std::tuple<Args...>>, ...) to explicitly disallow reference types that are not compatible with the json type. This is done because this function must return exactly the type in the identity_tag, but the function it calls will return values when dealing with incompatible references. This creates a dangling reference in the return. If desired, this static assert could be moved into an enable_if on the return to preserve SFINAE, but I could not think of a scenario where SFINAE would allow for recovery from this point during instantiation.
7. The addition of tests for get_to(std::tie(...)) and get<std::tuple<const T&,...>>() and to confirm arithmetic types do not try to pull references even when they are number types.

I would also like to potentially discuss modifying get_to to allow for rvalue references in cases like std::tie and mutable range views such as std::span (if it has not already been discussed).

• [x] The changes are described in detail, both the what and why.
• [x] ~If applicable, an existing issue is referenced.~
• [x] The Code coverage remained at 100%. A test case for every new line of code.
• [ ] If applicable, the documentation is updated.
• [x] The source code is amalgamated by running make amalgamate.

Read the Contribution Guidelines for detailed information.

(edited to reflect current implementation as of Nov 29)

[github-actions[bot]]

🔴 Amalgamation check failed! 🔴

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

[coveralls]

coverage: 99.192% (+0.001%) from 99.191% when pulling a583225da2ec3e18d090ee5851406599616087a1 on EALePain:reference_tuple_from_json into 02ac0d6525f2e046f136ca69b5105b4e4f315b2f on nlohmann:develop.

[EALePain]

ultimately I realized copy elation of the whole tuple is probably the more efficient route than elating moves for string, object, and array types allowed with the const reference returning overload.

[github-actions[bot]]

🔴 Amalgamation check failed! 🔴

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

[github-actions[bot]]

🔴 Amalgamation check failed! 🔴

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

[nlohmann]

🥳 Green CI! I will try to review this in the next week.