Peter Dimov

Although... why does Boost.JSON use BOOST_STATIC_ASSERT in standalone mode?

Same with all the other Boost macros - Boost.JSON shouldn't (re)define them.

``` bool op==( value const&, string_view) noexcept; bool op==( string_view, value const&) noexcept; ``` but this could introduce ambiguities.

I suspect it breaks currently working comparisons against initializer lists. Whether those are a feature is another story.

Initializer lists aren't necessarily `std::initalizer_list`s. For example, `{ 1, 2, "foo" }` is an initializer list, but not `std::initializer_list`. But it appears that I'm mistaken; Clang informs me that initializer...

Not a duplicate. That issue is about finding an element by its path, and this one is about inserting an element at a specified path.

We're having differences of opinion on what `jv.insert_at_pointer("/a/2", 5)` needs to create, an array or an object. @grisumbras thinks it should create an object and set its `"2"` key to...

There's no use case for (1) if you don't have (2)+(3).

(1) is useful if one has (3) and wants to maintain order independence as in ``` value jv = array(); jv.assign_at_pointer("/1/y", 5); jv.assign_at_pointer("/0/x", 3); ``` giving the same result as...

See also https://github.com/boostorg/json/issues/667.