Add dquotes around inf and nan when serializing to json

[captain-yoshi]

I think there is no way (as a number) to represent Infinity or NaN in JSON. One way would be to add them as strings.

Now what to do when converting to YAML... Should we keep the dquotes...

[biojppm]

Indeed JSON does not encode infinity or nan. Loading rapidyaml-emitted JSON into rapidyaml will work, so currently the library is at least self-consistent.

It is true that the missing quotes will make the JSON invalid according to the standard. However, if we add quotes in JSON and parse the result and emit in YAML, then these special values will be emitted with quotes, which makes them wrong in YAML, and then rapidyaml would lose the consistency there, or it would incur a significant cost while parsing by doing the string comparisons to remove the quoted flags.

I don't really see a good solution here, and for now I'm inclined to leave this situation as-is. I'll leave the issue open until a better solution appears, but I'm not convinced there is one.

[captain-yoshi]

If there was a way to format a float/double to a bit pattern in hexadecimal, then this could work. But I see JSON only accepts numbers as base 10... And the representation is different for a double with 32 vs 64 bits.

I also don't think there is a good solution. Thinking out loud, I would propose to add an option to format these numbers per user. I don't know the implication in the code, but adding a callback (when emiting to json) for each of these case, someone could handle these like so :

Double	yaml	json (user 1)	json (user 2)	json (user 3)
+∞	inf	biggest positive number	null	"inf"
−∞	-inf	biggest negative number	null	"-inf"
NaN	nan	null	null	"nan"

You obviously loose the consistency when re importing, but the user is aware of this tarde-off.

[captain-yoshi]

@biojppm I really think that the returned json should be valid. And I also agree that it should be self-consistent with this library when possible.

I would propose these changes to be done only when emiting to json :

Double	yaml	json	JavaScript -> JSON.parse()
+∞	inf	8e888	Infinity
−∞	-inf	-8e888	-Infinity
NaN	nan	null	null

This gives a valid json at the cost of a little inconsistency. When parsing this json back in ryml, the 8e888 is treated as a number and is close to infinity (wrt. popular standards, e.g. IEEE 754), and there is no need to do string comparison. Same thing with the null value. The 8 is for infinity and the high exponent is meant to go beyond an IEEE754 128 bit float max number (I think another digit or 2 should be added, but not sure).

• 8e888 = Infinity
• nan = null

I will probably go down this route, for my usecase.