Return null object from object's const operator[] as well.

[Tomeamis]

Currently const operator[] on object asserts if the key is not found. This is inconsistent with the non-const version, which adds and returns a null object.

IMO it should be possible to return a const reference to a static null json object.
This wouldn't be a breaking change, since it's currently UB. Unlike the non-const version, this wouldn't add anything to the subscripted object and would instead return a reference to a static object, but that should be OK, since it can't be modified anyways.

Specific use case for which this would be helpful:

struct Err {
	unsigned code;
	std::optional<std::string> message;
};

void from_json(const json &j, Err &err) {
	j["Code"].get_to(err.code);
	//assuming from_json for std::optional<T> already written
	j["Message"].get_to(err.message);
}

Currently this code would assert if Message is not present (Note that it is perfectly valid for non-const json objects), whereas with this feature, it would work as expected.

[nlohmann]

I am not convinced, but I am willing to discuss.

An extension of the from_json method is unfortunately not that simple (and std::optional not available in C++11).

[Tomeamis]

Extending from_json for std::optional can be handled in user code, and in any case is out of scope for this request.

Adding this would have negligible space overhead (just one json object), compared to the cost of the lookup, the cost of checking for the end iterator is negligible, and if I read the README correctly, this library is more about usability than performance anyways.
If implemented, it would remove one source of UB and surprise (there are already several issues open about this, for example #825, #1167, #1358), since the pattern json[key].is_null() would work for const as well as non-const references.
Possibly most importantly, it would free the programmer from having to keep in mind whether the reference they are working with happens to be const or not, since at present, if you either mistakenly call operator[] on a const reference or just make that reference that you've been using const, the program will only crash at runtime instead of causing a compiler error like most constness errors do.

If someone has a reason against this change, please comment it here, since I can't really think of one.

[Tomeamis]

Also, it doesn't introduce any traps, since mutating the result would be a compile error, and since the referred-to object would be static, there is no danger of a dangling reference.

[mika-fischer]

I have to agree that this would be a convenient addition. This has caused many bugs for us, because it is so easy to get wrong...

I also wonder what the rationale is for basic_json::operator[](... key) const to even exist in the first place. AFAICT this library aligns itself quite strongly to STL concepts, and in the STL there's no const operator[] for map-like classes.

[Tomeamis]

So since nobody supplied any reason why this would be outright bad, should I just make a PR?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.