Implicit conversions to complex types can lead to surprising and confusing errors

[tlemo]

Using std::vector as an example (since it's likely a popular scenario) illustrates how the implicit conversions (json::operator ValueType() const) result in a potentially frustrating errors:

Note that the assignment operator case (the last one) could be fixed by "more SFINAE": ignore any specializations of std::initializer_list. I don't see a generic solution for the other cases (this is just an example)

My suggestion is to scale back on the implicit conversions:

1. A moderate solution is to exclude any implicit conversions to non-scalar types (easy to implement)
2. The more radical, but the right solution long term IMO, would be to:

• add a "strict" compile time mode, where all the implicit conversions are disabled (operator ValueType and all the json constructors made explicit)
• deprecate and gradually remove the non-strict variant.

I realize that the 2nd choice seems a drastic departure and that some people are attracted to the initial convenience of implicit conversions (for large, complex project this short term convenience is likely a liability though).

Thank you!

json j = { 1, 2, 3 };

// works as advertised
std::vector<float> v = j;

// compiles, but likely not as intended:
// resolves to explicit vector( size_type count )
std::vector<float> v2{j};

// error: call to constructor of 'vector<float>' is ambiguous
// note: candidate constructors:
//   vector(const allocator_type& __a) _GLIBCXX_NOEXCEPT
//   vector(size_type __n, const allocator_type& __a = allocator_type())
//   vector(vector&& __x) noexcept
//   vector(const vector& __x)
//   vector(initializer_list<value_type> __l,
std::vector<float> v3(j);

// error: use of overloaded operator '=' is ambiguous (with operand types 'vector<float>' and 'json' (aka 'basic_json<>'))
// note: candidate functions:
//  operator=(vector&& __x) noexcept(_Alloc_traits::_S_nothrow_move())
//  operator=(const vector& __x);
//  operator=(initializer_list<value_type> __l)
v = j;

[theodelrieu]

The root of this problem is described in detail in #958, here you can show your support for the removal of operator T()!

Meanwhile, I would suggest ALWAYS using j.get<std::vector<float>>().

EDIT:

The "blacklist" will also break code, I'm personally in favor of the drastic solution, since implementing the first one is hard, especially if trying to get everything right...

[tlemo]

Thank you Theo, I'm not surprised that this has come up before. I've reviewed #958 and up voted it.

A few comments though:

1. I don't think that completely removing json::operator ValueType() is required or necessarily the best solution: marking it explicit should solve the same problems while still allowing reasonable ergonomics (direct initialization and explicit conversions). That being said, this distinction is not the critical issue and either solution would be great.

2. A similar problem does manifest the other direction as well: implicit conversions to json. In particular implicitly converting strings to json objects can lead to bugs which can't be detected at compile time:

json j = str; when json j = json::parse(str) was intended.

Side note: personally I'd love to see the parsing and formatting decoupled from the json type itself (which would incidentally allow for more flexibility for formatting customization), but regardless of that, I think that a more strict control over conversions serves C++ developers better.

[theodelrieu]

Great, thanks!

1. It would still cause many surprises, the different types of initialization is quite a dark corner for many people, whereas having to call get is a no brainer (if it is the one and only way to convert a json value). And it wouldn't solve the subtle errors like the Milliseconds/Nanoseconds example in the linked issue.

2. I don't really know what to think about that, would've to give some thought later on, do you have a rough idea of an API?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.