You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 26, 2020. It is now read-only.
@j4cbo might remember best the logic behind deciding not to do that (or the similar operator bool approach) when this library was first developed. My thought would be that it would be a pattern easy to misunderstand depending on your expectations of JSON. E.g. it's not obvious if it's checking only for null, or also for a boolean value (it's a bit awkward to have a boolean operation which has a different meaning from bool_value()), or integer values which C++ programmers would expect to be true if non-zero, or other values which would be defined as "falsy" by JavaScript or Python, like empty strings, empty arrays, etc. Making any test explicit rules out any confusion about what exactly it should mean.
Yep, that's exactly it. There are a bunch of possible meanings of an implicit boolean cast. Making the cast check only for null would be one option, but Javascript also has its own convoluted truthiness semantics which are kinda convoluted, and which users might expect. Any possible meaning of an implicit cast might be surprising to someone, so we decided to require that the intent be written out explicitly.
Oh, I didn't think of that about... Your decision seems reasonable, and I agree with that philosophy too.
Keep the most appropriate way of C++. Thanks for your explanation.
How about adding an logical operator
bool Json::operator! () const { return is_null(); }
?I'd like to use syntax like this:
The text was updated successfully, but these errors were encountered: