Inconsistent behavior between json::get and static_cast intended?

[pasbi]

I have a custom adl_serializer for std::optional<T>.
I'm able to deserialize std::nullopt from nlohmann::json{} using get, but static_cast fails:

• nlohmann::json{}.get<std::optional<double>>() returns nullopt as expected
• static_cast<std::optional<double>>(nlohmann::json{}) throws.

Is this behavior intended?

https://godbolt.org/z/TEGqnTcoP

[nlohmann]

With #4036 we recently updated the conversion from/to std::optional. Please check with the latest develop branch.

[pasbi]

It's the same on the develop branch.
Actually, the question is more general.
I supposed that static_cast and get do the same eventually and was surprised that they behave differently.
This particular case serves more as a kind of demonstrator.

So let me rephrase my question:
Is it intended that static_cast and get behave differently in some situations?

[pasbi]

Thanks for the reply.
Unfortunately this doesn't answer my question.
I know how get works and apparently it calls from_json.

The question is rather: Is it intended that static_cast doesn't work that way?

I always assumed that static_cast and get are different ways to express the same thing and that one is implemented using the other (I didn't bother to check that, frankly speaking).
While that's true for many cases, I have now found a case where it isn't true.

I think it'd be more intuitive not to have implicit nuances in behavior but rather make static_cast and get behave identically and, if required, provide another get_foo behaving differently.
But maybe I'm missing a point, that's why I'm asking if this difference might be intended.

[nlohmann]

I can't say much more. All the implicit conversions were deemed a bad idea in retrospective, so get was added.

[pasbi]

I agree that implicit conversions can be troublesome.
Takeaway for me is to prefer get over static_cast in future.

static_cast is an explicit conversion.
I consider it a bug that static_cast and get behave differently.

[nlohmann]

For this, we would need to make sure there are proper operator T(). Right now, some are missing. I'm pretty sure this can be fixed though. PRs welcome :)

[gregmarr]

I'm not sure that static_cast<std::optional<double>>(j) is something that the library can fix. Digging through the Compiler Explorer expansion with library functions not filtered out, static_cast<std::optional<double>> from json goes through the std::optional<double> constructor from nlohmann::json& and tries to in-place construct the internal double from it.

Here's the call chain with the long basic_json template replaced with just json.

std::optional<double>::optional<nlohmann::json&, true>(nlohmann::json&):

std::_Optional_base<double, true, true>::_Optional_base<nlohmann::json&, false>(std::in_place_t, nlohmann::json&)

std::_Optional_payload<double, true, true, true>::_Optional_payload<nlohmann::json&>(std::in_place_t, nlohmann::json&)

std::_Optional_payload_base<double>::_Optional_payload_base<nlohmann::json&>(std::in_place_t, nlohmann::json&)

std::_Optional_payload_base<double>::_Storage<double, true>::_Storage<nlohmann::json&>(std::in_place_t, nlohmann::json&)

nlohmann::json::operator double<double, 0>() const

This operator double<>() is where it blows up, because it calls from_json(..., double &) instead of from_json(..., optional<double> &). Since it's not a double, it throws the type error.

I consider it a bug that static_cast and get behave differently.

Note that the static_cast comes from std::optional and without your adl_serializer code, get doesn't even compile. The built-in std::optional<> support in the current head is through from_json and to_json, not get.

I did just try adding operator std::optional<T>() to basic_json and static_cast<std::optional<double>> still went through the std::optional template constructor.