Could we provide a more flexible get<> and at<> API?

[sighingnow]

What is the issue you have?

(I didn't see a "feature request" category when opening a new issue thus I post this ticket as a "bug report")

I'm wondering could we provides a more flexible get<> (get with key) or at<> (at with type parameter) API like:

template <typename ValueType>
ValueType get(const key_type &key) {
   return this->operator[](key).get<ValueType>();
}

template <typename ValueType>
ValueType at(const key_type &key) {
   return this->at(key).get<ValueType>();
}

I have notice we already has

• get with type parameter but without key
• at and [] with key but no type parameter
• value with key but requires a typed default value.

I think the new API above would provide great convenience.

Please describe the steps to reproduce the issue.

None.

Can you provide a small but working code example?

None.

What is the expected behavior?

As the description of this issue.

And what is the actual behavior instead?

No such API.

Which compiler and operating system are you using?

None.

[sighingnow]

If such API is acceptable, I could prepare a pull request for that.

[sighingnow]

Also for get_ref<>.

[nickaein]

Can you provide some code snippets that demonstrate the usage of this API?

BTW, there is a "Ideas" category at Discussions which seems to be meant for submitting proposals.

[sighingnow]

For example we have a json:

{
    "name": "foo",
    "age": 10,
}

And we want to get the age, before this proposal we need data["age"].get<int>(), after this proposal we just need data.get<int>("age"). The later is more concise and self-explaining IMO.

[sighingnow]

See also data accessor in boost::ptree: https://www.boost.org/doc/libs/1_65_1/doc/html/property_tree/accessing.html

[sighingnow]

@nickaein Any comment?

[gregmarr]

I don't see how the newer version is any more concise or self-explaining. It doesn't remove the need for json["keyname"] nor the need for json.get<value_type>(). It removes exactly two characters, which are punctuation. It puts the type before the key being looked up, breaking the association between the key and the json object. It is only valid for json variables that are objects, not those of any other type.

json["keyname"].get<value_type>()
json.get<value_type>("keyname")

It has the additional downside that it muddies the definition of get. The function can currently mean "get the value of this json variable which is of the given type". This would add an additional meaning of "check this json to see if this is an object. If it is an object, check to see if it has a nested value under the key "keyname". If it does, get the value of that nested object which is the given type. If any of those new things are not true, then .... <insert fallback behavior(s) here>."

The current method is not something that is difficult or wordy to do.

[gregmarr]

I don't think an additional function is needed. Adding = {} would make it work without that parameter for any default constructible type, and fail appropriately if it's not default constructible. I'm not sure if this was previously considered in the design of this function. @nlohmann would probably remember.

[nlohmann]

So you would propose chaning

template<class ValueType>
ValueType value(const typename object_t::key_type& key,
                const ValueType& default_value) const;

to

template<class ValueType>
ValueType value(const typename object_t::key_type& key,
                const ValueType& default_value = {}) const;

?

[sighingnow]

Agree with @gregmarr , I realized that it could fail appropriately if it isn't is_default_constructible and no default value.

Just add a default parameter = {} is fine for me.

[gregmarr]

I don't have a particular need for it, but if @sighingnow thinks it would make the function more useful, then yes.

[sighingnow]

Thank you @gregmarr, I will make a pull request for it.