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.
I came across this issue
#2159
as I was trying to do the same for
std::chrono::duration
. I searched around (though admittedly not much) on whether or not it's been discussed already to directly support
std::chrono
types right out of the box. I figured it would be simple enough (maybe naively) to add support for this in the library, but wanted to get educated a bit more on why this may or may not be a good idea.
My initial thought is that I wouldn't want to force everyone to transitively include the
chrono
header, but maybe that is just a matter of making it opt-in?
That would tie all users to a particular representation, which would be a compatibility issue for anyone that is currently using the library with
std::chrono::duration
, and as you say adds the
chrono
header.
Providing it as an opt-in method that people can put in their own code base, as it is now, is IMHO the most compatible route. It could maybe be provided as a more complete example.
Ahh gotcha. In my project I do not require serializing values out, so I hadn't even considered what the going that way actually looks like, and even more specifically I am currently only looking at
std::chrono::duration
values (where I am not parsing a unit or anything, but just a raw value) and so things are much less up for interpretation. e.g. in my project I have:
namespace nlohmann
template <typename Rep, typename Period>
struct adl_serializer<std::chrono::duration<Rep, Period>>
static void from_json(const json& j, std::chrono::duration<Rep, Period>& duration)
duration = std::chrono::duration<Rep, Period>{j.get<int64_t>()};
which I use to parse things like:
"time_ns": 1000,
to get time_ns read directly into a std::chrono::nanoseconds variable (previously I needed to read into a int64_t and then construct the std::chrono::nanoseconds which was fine but a bit clunky. Going the other way, I would have opted to forgo adding a unit since that would necessarily change the JSON value to a string. I also understand that using a raw value while the key contains the "unit" is less than ideal for a number of reasons.
I guess this is more of a philosophical question - is providing nothing better than providing some default? I understand if the answer to that question is yes. Is there no sensible default that works for "most" (I realize that "most" is impossible to measure 😃)?
I guess this is more of a philosophical question - is providing nothing better than providing some default? I understand if the answer to that question is yes. Is there no sensible default that works for "most" (I realize that "most" is impossible to measure 😃)?
Yes, it is better to provide nothing if the user can't override it, as it breaks existing programs.
Fortunately, it appears that the adl_serializer method can override the built-in to_json and from_json functions. So they could be added using direct to_json and from_json as was done for std::optional.
The question then is how to do it. Does it just record the count and assume that the user gets the period right, or does it try to record the period too, and validate it on restore?
