Behavior differences in operator[] object creation with a json_pointer

[nlohmann]

Discussed in #5356

^{Originally posted by samcmill August 3, 2026}
The following code throws a parse_error.106 exception due to the 01 token.

#include <iostream>
#include <nlohmann/json.hpp>

using json = nlohmann::json;

int main() {
    json obj = json::object();

    auto ptr = json::json_pointer("/a/b/01/d"); 

#ifdef INIT
    obj[json::json_pointer("/a/b")] = json::object();
#endif

    obj[ptr] = "value";

    std::cout << obj << std::endl; // prints {"a":{"b":{"01":{"d":"value"}}}}
}

However, if the first part of the JSON object up to 01 is pre-initialized, then the '01' token is treated as a string and the code runs successfully.

1. Is this expected behavior? It seems unintuitive to me. Regardless, I am currently taking advantage of this behavior by walking the json_pointer and pre-initializing to handle cases like this.
2. Would it make sense to have a mode where all json_pointer tokens are always treated as strings?

Related: #4446

[samcmill]

Thanks for jumping right on this!

The original request in #5356 was a mode where all tokens are treated as strings. This PR does not do that; it only removes cases where the heuristic picks a type that provably cannot work. A real "always object" mode would need new API surface and could be discussed separately.

FWIW, my use case is constructing a JSON representation of the /sys pseudo filesystem, with file system paths mapping to JSON pointers. Some paths may be technically invalid JSON pointer tokens, or have different semantics, e.g., /sys/.../cpu/1/.... A "always object" / "treat everything as a string" mode would simplify this use case.

That said, I am fine with a workaround like the one above. And I have no objections to addressing the issues separately.