Couldn't find these functions:

[suprith-hub]

I tried to run the given example, but parse_json() isn't recognized and I couldn't even find it in any of the files
https://github.com/sourcemeta/jsontoolkit/blob/fc64f54ce7dd80778ec4a759cbe732a87168c500/src/json/include/sourcemeta/jsontoolkit/json_value.h#L707

This works bu I couldn't locate the function insert_or_assign() and I wanted to know where it is coming from
https://github.com/sourcemeta/jsontoolkit/blob/fc64f54ce7dd80778ec4a759cbe732a87168c500/src/json/include/sourcemeta/jsontoolkit/json_value.h#L1124

[jviotti]

On parse_json, thanks for the heads up. The docs are wrong. There used to be parse_json, which was eventually replaced by just parse. I probably just forgot to update those. Here is a PR: #562

[jviotti]

@Era-cell If you find more incorrect documentation snippets please let me know. Very valuable to spot them and fix them, as there is no way to automatically test these example snippets! (there might be some more out of date)

[suprith-hub]

Yeah! cool👍

[jviotti]

On insert_or_assign, that's coming from the C++ standard library for std::map (the associative map container type we are using to model JSON objects): https://en.cppreference.com/w/cpp/container/map/insert_or_assign

[suprith-hub]

I got it!!
1.I think that is cool, also "insert_or_assign" in map is same as" assign "here..
2. Also there are 2 funtions for assign, one taking const GenericValue other normal.

• what difference does it make by using std::move, and assigning just value? Why not use std::move for both as it is optimal to do so

[jviotti]

On number 2, not every type can or should be moved. For example, a user might have a const reference to something they don't own, and thus copy is the only way to do it, or even if they could move it, it makes sense for their specific case to copy. It is common for C++ containers to provide overloads for both cases and then you can pick which one you want depending on what you want. If you have an rvalue (movable type), you will get that, otherwise you get the other one

[suprith-hub]

Cool! I learnt about lvalue and rvalue references.
So, the conlusion is: we don't want lvalue references to be destroyed. It was an interesting topic

[jviotti]

we don't want lvalue references to be destroyed

I guess the conclusion is that "it depends" and you rather give the developer the choice! This is a good book on the topic btw: http://cppmove.com