json_pointer public push_back, pop_back

[HugoLopata]

Feature Request
I am generating some json pointers. It would be handy using push_back instead of composing string with slashes, which is subsequently broken to vector of strings by json_pointer.

Access to internal data may be handy too:
const vector<string>& json_pointer::impl() const;

[nlohmann]

I think this addition makes sense - especially as reference tokens are stored inside a vector internally.

[nlohmann]

@HugoLopata I added the functions to a feature branch, see 516d4e6. Is this what you had in mind?

[HugoLopata]

Yes, exactly as expected.
Please add note to the documentation about difference between constructor and push_back.
Push_back do not unescape and slash is simply slash. See an example.

json::json_pointer ptr1("/foo/bar~0baz");
json::json_pointer ptr2;
ptr2.push_back("/foo/bar~0baz");
std::cout << "ptr1: " << ptr1.to_string() << '\n'; // /foo/bar~0baz
std::cout << "ptr2: " << ptr2.to_string() << '\n'; // /~1foo~1bar~00baz

Consider also adding some examples with escape characters to the tests.

[nlohmann]

Oh I did not think about escaping. What do you think? Should push_back escape slashes?

[HugoLopata]

• Variant 1: Single level, unescaped - as proposed in patch. This behavior is little bit inconsistent. Push_back is single level operation. No escaping needed. -> Simple usage, i like it.
• Variant 2: Single level, escaped - if you use the same algorithm as in constructor, then slashes should be denied (user should use ~0 instead). Consistent with constructor, but user has to do escaping (some public static string escape(const &string) will be convenient then).
• Variant 3: Multilevel push_back. I don't like it.

[theodelrieu]

I am not fond of push_back, it's way too associated with containers.

However I think adding both operator/ and operator/= would be great.

Whether these escape or not should depend on the most intuitive/expected outcome. I've never used JSON pointers, so this should be agreed upon by experienced users.

Anyway we have to support both cases, so mimicking std::filesystem::path seems reasonable (i.e. having operator+= and concat)

Boost.Filesystem decided to not have an operator+, I haven't seen the exact rationale, but my guess would be that they feared a lot of misuses would have happened with it.

I believe json_pointer is very similar to std:: filesystem::path, so having a similar interface makes sense to me.

[nlohmann]

I agree that push_back is indeed associated with containers, and I think the idea of operator/ and operator/= is charming.

[nlohmann]

I will postpone a decision for this after the 3.0.0 release.