Make cast from basic_json<T1> to basic_json<T2> explicit

[YarikTH]

As I can see adding of ordered_json added a lot of confusion.
#2539
#2528 (comment)

And I think that some of the confusion could be prevented via disabling potentially unwanted behaviour.

How about making cast from one basic_json type to another basic_json type explicit?
So

ordered_json oj = json::parse(input);
oj["test"] = "{}"_json;

Won't longer compile and need explicitly cast it to desired type?

ordered_json oj = static_cast<ordered_json>( json::parse(input) );
oj["test"] = static_cast<ordered_json>( "{}"_json );

It's a breaking change, but it should be a good candidate for 4.0. Or it can be added as a new default behaviour with ability to have implicit casts via some define.

I think that code that doesn't compile should be a good hint that user did something wrong.

static_cast is ugly, but I'm sure most of such implicit conventions were made by mistake anyway, so broken code should be changed to use correct basic_json type.

[nlohmann]

Note: We already have a macro to disable implicit conversions.

[YarikTH]

So the question is: is it a good idea to make "disable implicit convertions" a new default behaviour?
Because with 2 default basic_json overloads and documentation mostly describing only work with default "json" type users don't fully understand how to work with ordered_json. defaulted implicit conversion between them doesn't help.

[YarikTH]

Maybe I do something wrong, but it doesn't seem like "macro to disable implicit conversions" works with basic_json interconversions:
https://godbolt.org/z/E98oKq
https://godbolt.org/z/7zbK39

[nlohmann]

Sorry, my bad. So this is less about implicit conversions than about documentation.

• for [ordered_json], the member function [parse] do not support keeping order of the input #2539 is an example of converting unordered JSON to ordered JSON. It's more or less "explicit" in the sense that both types are mentioned in the same expression. I'm not sure whether this should be forbidden.
• Cannot assign from ordered_json vector<CustomStruct> to value in not ordered json #2528 (comment) is an example for the rough edges we left when the ordered JSON values were introduced. There is still some work to be done, but in the end, I do not see a reason to break the API for this.