get<T> for types that are not default constructible

[bradymadams]

Currently the get<T> method requires that T is default constructible. Might it make sense to overload get so that it can take variadic arguments and construct the new object with a non-default constructor? For example - below is a minor variation of get. Any reason why this is a bad idea?

template<typename ValueTypeCV, typename ValueType = detail::uncvref_t<ValueTypeCV>,
         detail::enable_if_t <
             not std::is_same<basic_json_t, ValueType>::value and
             detail::has_from_json<basic_json_t, ValueType>::value and
             not detail::has_non_default_from_json<basic_json_t, ValueType>::value,
             int> = 0, typename ...Types>
ValueType get(Types... args) const noexcept(noexcept(
                                   JSONSerializer<ValueType>::from_json(std::declval<const basic_json_t&>(), std::declval<ValueType&>())))
{
    // we cannot static_assert on ValueTypeCV being non-const, because
    // there is support for get<const basic_json_t>(), which is why we
    // still need the uncvref
    static_assert(not std::is_reference<ValueTypeCV>::value,
                  "get() cannot be used with reference types, you might want to use get_ref()");

    ValueType ret(args...); // Allows non-default constructors to be used
    JSONSerializer<ValueType>::from_json(*this, ret);
    return ret;
}

[nlohmann]

Do you have a concrete example for this?

[theodelrieu]

There is a way to deserialize non-default constructible types, you can see this section for more details.

[theodelrieu]

As for your suggestion, the problem is that from_json functions overwrite the ValueType object.

Even if your from_json functions take care of the already constructed value, it would have to handle the different calls to get, e.g.:

j.get<MyClass>(1, 2); // first constructor
j.get<MyClass>(); // default constructor
j.get<MyClass>("") // another constructor 

I think this can lead to lots of complex handling inside functions, so I would rather keep the conversion functions with lowest side-effects as possible.

[bradymadams]

Just to make sure I understand - your concern is different constructors might leave the ValueType object in different states. It would get complicated for from_json to figure out the state of the object since there's no easy way of telling which constructor was used. Is that correct? That isn't something I thought of and it makes sense.

I can use the approach of specializing adl_serializer as you mentioned above. Thanks for the help!

[theodelrieu]

Yes that's exactly it :)

[nlohmann]

Thanks @theodelrieu !