I support this PR.

Replacing NaNs with null is what the Javascript JSON.dumps implementations does in at least Firefox and Chrome (likely mandated by web standards), so that aspect of this PR matches standard Javascript usage of the Javascript Object Notation format.

Replacing infinities with 1e99999 causes any real-world decoder to produce the same number as was used to encode the JSON. It is incredibly rare to parse JSON with bignums, and if anyone is doing so, they're not matching Javascript behavior (e.g. they're going to get incorrectly-rounded decimal values out of it). Javascript JSON.dumps produces null instead, but there's absolutely no reason to do that; 1e99999 is an entirely 100% unobjectionable perfect fix.

This PR causes Godot to fall in line with the rest of the JSON ecosystem and fixes compatibility problems. The only Godot users it breaks are people who are incorrectly using JSON as a generic stringification method AND ALSO depending on the textual values of broken JSON strings. But in principle, this is no more of a breakage to such misuse of the JSON API than changing the number of digits that normal, finite floating point values are printed with, which nobody would object to if it was a fix for a hypothetical bug where Godot wasn't producing floating-point text with enough precision to reproduce them accurately during parsing.

What do you think about not converting these values ​​at all? Or converting them as you did but generating an error/warning? I don't see any error/warning prints or documentation changes in your PR.

Since the JSON specification doesn't support NaN and infinities, strictly speaking, they are unrepresentable (there is no bijective mapping). While you can still rely on scientific notation and overflow for infinities (which may still be implicit and not guaranteed to work for 100% of parsers), you can't represent NaN at all and you are forced to replace it with null or "NaN".

Yeah, the NaN situation is very unfortunate. But I think that the browser Javascript APIs converting it to null is in strong favor of going with that; it's consistent with the overwhelmingly most-used JSON encoding API. I poked around and it's rare for the built-in JSON APIs of dynamically typed languages to throw errors when encoding strange values. gdscript's JSONizer doesn't throw errors when you try to convert Vector3s to json, for example, it just stringifies them.

@dalexeev What does "not converting" actually mean? Returning null? Returning an empty string? This function has to return some value, even if it prints an error or warning.

For NaN, my PR originally had null, but there was feedback that it should be "NaN", so I changed it. I would be happy to change it back to null if that is the consensus. I don't mind either way, but I am opinionated that Infinity is best serialized in JSON as 1e99999.

Oh, I didn't realize you changed it from null to "NaN"! I'm okay with either, but I'd prefer null for consistency with browsers.

My memory of the core team meeting was that we were fine with correcting this behavior, but that we wanted to match the behavior of another big project, so that we weren't putting another unique solution to this problem out into the world.

Which other project's behavior does the current version of this PR match?

What does "not converting" actually mean? Returning null? Returning an empty string? This function has to return some value, even if it prints an error or warning.

If we supported exceptions, the stringify() method would probably throw an exception in this case. If we supported nullable, union, or generic types, the return type would be String?, Optional[String], String|Error, Result[String], or something similar.

With the current approach, we could use an empty string as an error indicator and document it, but that's probably not a good idea, given how many users forget to check the result before using it. So we should probably try to fallback to the most reasonable value on a best-effort basis.

In my opinion, we should use your approach or something similar to get a valid JSON, but additionally generate an error/warning to let the user know that NaN and infinities ​​are not supported in JSON in the first place. But I'm not insisting that this should be done in this PR, since the stringify() method is currently generally quite tolerant of invalid values ​​and silent about possible user errors.

@dsnopek As written in the description of the PR, graphite-project/graphite-web#813 is what I found in a quick search (IIRC, it was linked to in several places), and as such when I originally opened PR #108837 it had the same behavior as that (big number literals for infinity, and null for NaN). Then there was feedback in the comments of PR #108837 that strings are desired, since that is opt-in behavior in C#, with the default being to throw System.ArgumentException, but we don't have exceptions in Godot's C++ code, so I then changed the PR to use "NaN" for NaN. Similarly to C#, Python throws ValueError by default, but unlike C#, its opt-in option is to emit invalid JSON, which is bad.

As for infinity, big number literals are still the unambiguous best option for encoding Infinity, it can be decoded correctly everywhere as far as I'm aware. The tricky one is NaN. Since both JavaScript and Graphite output null by default, it may be best to change this PR to null, as I originally opened the first iteration of PR #108837.

I would be happy to take any other language or project's behavior into consideration... just name it.

I updated this PR with these changes:

• Serialize NaN as null instead of "NaN".
• Print a warning when encoding NaN similar to PR Core: Enforce strict JSON for non-finite numbers, document native workaround #111608 (not the same message, and not for Infinity)
• Add a warning to the documentation similar to PR Core: Enforce strict JSON for non-finite numbers, document native workaround #111608 (not the same docs, but similar, thanks @Repiteo).

Thanks (again)!