Remove undefined behavior for const operator[]

[Xylaant]

• Describe the feature in as much detail as possible.

In most places in the library, when using a non-const object, attempting to access a non-existent array value or key via the operator[] methods will result in creation of those methods. On the other hand, if the basic_json object is const qualified, then for arrays operator[] results in undefined behavior, where for objects it acts more like the at() function with an exception.

I'd like to propose modifying the implementations of the const overloads of operator[] to instead return a const-reference to a static instance of an empty basic_json<> object. There are a handful of ways to do this (static data member or static singleton method). This would mean that you can't easily slip into undefined behavior/exception by adding const qualifying a json object.

[nlohmann]

A lot of people were annoyed by the behavior of operator[], but this is the first time someone actually has a constructive proposal how to improve the situation. I will consider this after the 3.8.0 release.

[Xylaant]

As part of the discussion, what do you think the correct behavior of operator const and operator const be if is_null() is true. For the non-const version, it converts the object to an array or object.

If the code were to return a constant reference to a nil object in the not-present case, should it also do that in the is_null() case? The current behavior would be to throw an exception. Is it worth considering have it just return the same null object?

[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.

[eferreira]

A lot of people were annoyed by the behavior of operator[], but this is the first time someone actually has a constructive proposal how to improve the situation. I will consider this after the 3.8.0 release.

For the record, I suggested this exact possibility in this thread back in 2017: #289 (comment)

would still love for it to make it into the official library in some form or another, for all the same reasons that I went into back then.

[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.