Extending get<T> with additional arguments necessary for conversion

[croemheld]

First of all, the library is absolutely superb. I recently faced a situation where I wanted to write a custom from_json function in order to convert a nlohmann::json instance to an arbitrary type, which required additional parameters (e.g., a lookup table). Is there a way to extend the get<T>() method with something like that? An example would look like this:

#include "json.hpp"
using json = nlohmann::json;
// ...
void from_json(const json& JSON, ArbitraryType& AT, std::map<std::string, std::string>& LookupTable) {
    // ...
}

And the usage of this would be something like:

json JSON = // ...
ArbitraryType AT = // ...
std::map<std::string, std::string> LookupTable = { /* ... */ };
JSON.get<ArbitraryType>(LookupTable);

Of course, it doesn't have to be the get<T> method, a new method like:

template <typename T, typename ... Args>
void get_with_args(Args&&... args) {
    // ...
}

which contains a call to the custom from_json function implemented by the user, just as shown in the first code snippet. And this would be useful if not everything can be initialized in the arbitrary type just from the nlohmann::json object alone.

Right now, I am unable to use the get<T> or any from_json functions since they do not accept additional arguments that are necessary to completely initialize the arbitrary object.

I am currently not too well versed in the library, so if this request would be seen as useful, I would love one of the more proficient developers of this library to give me some pointers in how to achieve that in order to write a pull request.

[gregmarr]

If you are always going to be using it like this (note the difference between get and get_to below):

json JSON = // ...
ArbitraryType AT = // ...
std::map<std::string, std::string> LookupTable = { /* ... */ };
JSON.get_to<ArbitraryType>(AT, LookupTable);
ArbitraryType AT2 = JSON.get<ArbitraryType>(LookupTable);

then you could just as easily skip the get or get_to part and just use your own function:

void ReadFromJson(const json&, ArbitraryType &AT, LookupTableType& LookupTable) {
    // ...
}

json JSON = // ...
ArbitraryType AT = // ...
std::map<std::string, std::string> LookupTable = { /* ... */ };
ReadFromJson(JSON, AT, LookupTable);

[croemheld]

This is what I am currently doing: I do not use any of the get<T> or get_to<T> methods. Instead, I use a custom function that essentially contains the same arguments plus the additional ones.

But it seems like this is not reason enough to extend the API, even though it would, at least in my eyes, lessen the amount of boilerplate code. An std::vector<ArbitraryType> (with ArbitraryType requiring an additional parameter to enable a conversion from nlohmann::json) would require me to write at least 2 more functions, in one of which I have to also iterate over the std::vector, emplacing an empty object of type ArbitraryType, before finally calling get_to<T> on the new element.

For now, I use a custom template function like this:

/**
 * @tparam DestTy The member type which to populate.
 * @tparam Args Type of the additional arguments.
 * @param JSON The reference to the nlohmann::json object.
 * @param Property The JSON property which to look up.
 * @param Dest The member which to populate.
 * @param args Additional arguments necessary for the population.
 * @return True, if the specified property exists, otherwise false.
 */
template <typename DestTy, typename ... Args>
bool getJSONPropertyAt(const nlohmann::json& JSON, std::string_view Property, DestTy& Dest, Args&&... args) {
  if (!JSON.contains(Property))
    return false;
  return getJSONProperty(JSON.at(Property), Dest, std::forward<Args>(args)...);
}

where getJSONProperty is the equivalent to nlohmann::json's from_json function with ADL. It works perfectly fine that way, which is why I thought it would be an idea for a small extension for the library.

[gregmarr]

It sounds like a small extension, just changing get and get_to, but then it cascades into from_json. From your example, in order for it to be there for getting an array of ArbitraryType, it would have to be added to from_json(..., std::vector<ArbitraryType> &) as well, and pass that data along to the individual calls.

I was thinking that you might be able to put the data on the json object using a derived class, but then you'd still need to pass it down an object tree, since the json object on which you call get<std::vector<ArbitraryType>> is not the same object on which get<ArbitraryType> is called for the individual elements.

[gregmarr]

I wonder if you can do something with the CustomBaseClass support that was added recently. #3110

[croemheld]

I redesigned my implementation a bit and added a partial specialization for std::vector. This is what it looks like now and I plan to use that. If there is ever gonna be a slim chance that this might get integrated, it could maybe build on top of that. For now, this is only the from_json function.

namespace ns {

namespace adl_json {

template <typename T, typename ... Args>
struct from_json_function {
  void operator()(const nlohmann::json& JSON, T& t, Args&&... args) {
    from_json(JSON, t, std::forward<Args>(args)...);
  }
};

template <typename T, typename ... Args>
struct from_json_function<std::vector<T>, Args...> {
  void operator()(const nlohmann::json& JSON, std::vector<T>& v, Args&&... args) {
    for (auto &Element : JSON) {
      v.emplace_back(T());
      from_json(Element, v.back(), std::forward<Args>(args)...);
    }
  }
};

}

template <typename T, typename ... Args>
void from_json(const nlohmann::json& JSON, T& t, Args&&... args) {
  adl_json::from_json_function<T, Args...>()(JSON, t, std::forward<Args>(args)...);
}

By far not as elegant as the original, but at least it's relatively easy to extend thanks to ADL. As the std::vector part with additional arguments is already covered, I only need to add the following for ArbitraryType:

void from_json(const nlohmann::json& JSON, ArbitraryType& AT, /* ... */) {
    // ..
}

I can already see a case where I would need to extend it for std::map, but that essentially the same procedure as for std::vector. Should probably add a check for whether or not T is movable as well.