Add a customization point for user-defined types

[theodelrieu]

Hi, I think it would be a cool addition to the library if there was a way to specify a conversion method, from a type to basic_json, which would be called by the lib.

Here a sample code of the behaviour I'm thinking about:

// library code
template <typename UserDefinedType>
struct json_traits;

// user code
template <>
struct json_traits<MyType>
{
  static basic_json convert(MyType const& val)
  {
    return {{"first_row", val.first_row}, {"some_value", 42}};
  }
};

There could also be a conversion method when get is called

auto obj = json::parse(buffer);
auto val = obj["user_defined_type_value"].get<MyType>();

These are just thoughts for now, but that would remove a LOT of boilerplate in my code.
Plus, this would add some compile-time checks (if the struct is not defined for example)
What's your opinion on that?

[gregmarr]

That would be cool. I created to_json and from_json functions for a lot of my types, and use to_json/from_json exclusively even for types it already supports. Making them work automatically out of the box would be even cooler.

[nlohmann]

This issue is related to #298 and #280.

[nlohmann]

I have not understood the role of json_traits completely. Shouldn't there be a constructor in the basic_json class for the json_traits template? Would this constructor then be usable for any class that is specialized by json_traits?

[gregmarr]

It's all static functions, the class is never instantiated.

[nlohmann]

I still do not understand what to add to the basic_json class.

[gregmarr]

Maybe something like this:

template<typename T> basic_json(T&& val) :
    basic_json(json_traits<T>::convert(std::forward<T>(val)))
{
    assert_invariant();
}

There might also need to be some enable_if code to keep the current constructors working, or maybe the current constructors become specializations of the json_traits class instead. (Though that using specializations part might get into cyclical dependencies.)

[gregmarr]

Yeah, this is basically what @gnzlbg and @d-frey described in #298

[theodelrieu]

Indeed, looking at taocpp value.hh and traits.hh can help to understand the idea

[theodelrieu]

I started a POC on my fork. (I didn't modify the re2c file, but I will !)

[theodelrieu]

There is an issue with that ctor however...

// not equality-comparable
struct S{};

int main()
{
// this will call operator==(basic_json, basic_json) if json_traits<S> was specialized
// and it will do so for every operator defined for basic_json ...
  S() == S();
}

I'm looking for a way to bypass this, without making the constructor explicit

[gnzlbg]

(json_traits::convert(std::forward(val)))

What is the advantage of json_traits<T>::convert over a simpler json_convert free function that is found via ADL ?

[theodelrieu]

@gnzlbg one thing that comes to mind is the ability to partially specialize the struct

We could imagine a specialization for boost::optional for example

template <typename T>
struct json_traits<boost::optional<T>>
{
   // ...
};

[gnzlbg]

What's wrong with just using overloading?

template <typename T>
auto json_convert(boost::optional<T> const&) -> basic_json { ... }

(note: json could include these overloads in some separate header, but they would add a dependency on boost::optional).

I find that for most people free functions and overloading are easier to understand than trait classes and partial template specialization. One thing overloading allows is to implement json_convert once for all Optional-like types (given an OptionalLike concept that requires .value() and explicit operator bool) using enable_if (behind a CONCEPT_REQUIRES_ macro like in, e.g., range-v3):

template <typename Optional, CONCEPT_REQUIRES_(OptionalLike<Optional>{})>
auto json_convert(Optional const&) -> basic_json { ... }

(note: since boost/std/...::optional is not directly used here, json could actually add this overload without introducing a dependency on any of these libraries).

EDIT: Doing the same with partial template specialization is a bit "more hacky" since it would require not only requires and an OptionalLike concept but also void_t (which while simple to write, is a bit harder to understand why it works).