alienvalkyrie Reply To cazfi
if the implementation uses similar pattern as float one.
I'm not sure how sensible that is. Which is to say, I'm not convinced the way we currently handle floats is sensible – they're basically transmitted as fixed-point numbers, which runs counter to them being, y'know, floating-point. That said, I don't think there is a good, general way to do fixed-point numbers so long as we're stuck with C (especially not without C23 features). But if we do decide to make a floating-point/fixed-point distinction, we should probably implement that before expanding to doubles.
As far as I can tell, there doesn't seem to be any pertinent reason why floats are handled this way; if there is, it isn't documented in the obvious places. Presumably, it would've been to avoid having to invent get/put_float() functions way back in the pre-dataio days when the space race we know today took shape.
Which is to say, there's probably nothing stopping us from actually just transmitting the floats directly. (Which the JSON protocol already does, modulo stringification.)
Since I've already mentioned C23 features earlier: If we consider making use of _BitInt(N), that could affect (possibly streamline or expand) integer handling and thus the realization of 64-bit integer support.
Also, note that depending on JSON decoder and its configuration, all numbers might be decoded Javascript-style as doubles, which can't accurately hold integers greater than 253; for Jansson, this seems to be controlled by the JSON_DECODE_INT_AS_REAL flag.
Reply To alienvalkyrie
Reply To cazfi
if the implementation uses similar pattern as float one.
I'm not sure how sensible that is.
I should have put that 'if' in the beginning of the sentence bold ;-)
While I'd prefer better pattern, I'm sort of ready to accept the current one. That is of course seeing the use-case being decimal numbers and not really so much floating point. Maybe we should change the naming of the types to reflect that? And to reserve terminology like "float" to something where the point really floats? (If such rename deemed a good idea -> open a new ticket)
Also, general note to this discussion is that floating point numbers are inherently inaccurate, and in any case their user should not make too strict assumptions about the accuracy they receive (As often instructed: "Never compare floating point numbers with '==' but with an acceptable range")
I'd like to have double support in the network protocol, e.g., to have cleaner solution to ping time accuracy window issues than what we currently try to do. I think 64bit integer types are a prerequisite for that, at least if the implementation uses similar pattern as float one.
I don't expect big compatibility issues, but neither is this very urgent, so lets follow the practice of preferring to have such requirement bumps in the beginning of a major version cycle -> targeting 3.3