Clarify implementation limits on NaN and Infinity

[ell1e]

I am thinking about adding support for JSON5 in a programming language that doesn't have NaN as a numeric value (operations that would produce it cause an exception instead). Is there any suggestion or experience of others in regards to what should I do in such a case with JSON5 that contains a NaN? Is there a name of a subset that is "JSON5 but not a NaN" that I could refer to so people don't get confused when I reject these values? I'm not sure what's the best course of action here

Sorry if this is not the right place to ask this, I'd be happy to close this and ask somewhere else!

[jordanbtucker]

Thanks for the question. If you have questions about how to interpret or implement the JSON5 specification, then you've come to the right place.

NaN and Infinity have always been a point of contention for me since I joined this project. I figured an issue like this would come up eventually.

It's okay to reject a JSON5 document that contains NaN if your platform doesn't support it. In the same way, it's okay to reject a JSON5 document that contains a number with more digits than your platform can represent, or a string so long, or a set of objects so deep, that it would overload the memory.

Alternatively, it would also be okay to just convert the offending JSON5 values to data that your platform can represent, possibly with a warning attached to it. For example, you could convert a large number to infinity, or truncate a large string, or stop nesting objects beyond a certain depth. See the Python and PHP implementations of JSON for examples.

While many JSON libraries have extended JSON to support NaN, there isn't really a precedent for platforms that don't support the features of JSON or JSON5. In the case of NaN, I'd probably just return whatever null is in your platform and produce a warning along with it (since JSON implementations typically convert NaN to null when encoding). Or perhaps you'll want a flag that users can give to the parse function that determines whether to throw, convert, or ignore NaN values.

In the end, it's really up to you. I hope that helps.

[jordanbtucker]

Additionally, I think it's best to give developers the option to parse JSON5 documents even if they contain NaN. Often times, developers do not have control over what a JSON5 document contains, so flat out rejecting an entire document because it contains NaN, without offering an alternative, will probably not be a pleasant experience for developers.

[ell1e]

Ok. In that case I would suggest to expand this:

An implementation may set limits on the size of texts that it accepts, the maximum depth of nesting, the range and precision of numbers, and the length and character contents of strings.

into something like:

An implementation may set limits on the size of texts that it accepts, the maximum depth of nesting, the range and precision of numbers as well as support of +inf/-inf/NaN, and the length and character contents of strings.

[aseemk]

(@jordanbtucker: just want to say you continue to kill it as a maintainer and steward of this project, and I appreciate that very much. Thank you! ❤️)