| 14 Aug 2025 |
 WeetHet | In reply to @raitobezarius:matrix.org
In ~ 5 days, yeah Thanks | 15:38:15 |
 emily | ok, I-JSON says
Software that implements IEEE 754-2008 binary64 (double precision)
numbers [IEEE754] is generally available and widely used.
Implementations that generate I-JSON messages cannot assume that
receiving implementations can process numeric values with greater
magnitude or precision than provided by those numbers. I-JSON
messages SHOULD NOT include numbers that express greater magnitude or
precision than an IEEE 754 double precision number provides, for
example, 1E400 or 3.141592653589793238462643383279.
An I-JSON sender cannot expect a receiver to treat an integer whose
absolute value is greater than 9007199254740991 (i.e., that is
outside the range [-(2**53)+1, (2**53)-1]) as an exact value.
For applications that require the exact interchange of numbers with
greater magnitude or precision, it is RECOMMENDED to encode them in
JSON string values. This requires that the receiving program
understand the intended semantic of the value. An example would be
64-bit integers, even though modern hardware can deal with them,
because of the limited scope of JavaScript numbers.
| 15:38:53 |
| emily | ok, Nixpkgs does in fact detect the float case for integer conversions | 15:39:36 |
| emily | so "fits into Nix integer → Nix integer, otherwise → float" would be desirable for Nixpkgs and consistent with other JSON implementations | 15:39:58 |
| emily | "fits into Nix integer → Nix integer, otherwise → error" would be acceptable for that too, but less interoperable with other JSON implementations and weird per the spec | 15:40:28 |
| emily | since adding a .0 isn't really meant to change a number by the specced JSON semantics | 15:40:39 |
| emily | and indeed builtins.fromJSON "1.0" is 1 | 15:40:50 |
| emily | oh wait 1.0 also prints as 1 | 15:41:01 |
| emily | nix-repl> builtins.isInt (builtins.fromJSON "1.0")
false
ok never mind :)
| 15:41:12 |
| emily | anyway my point is just that we should pick one. the current behaviour is incoherent | 15:41:27 |
 aloisw | Apparently that behaviour even changed, I remember it throwing or converting to float depending on the number of digits but now the float only happens when out of the unsigned range. | 16:27:10 |
| emily | yes | 16:42:22 |
| emily | it was changed when banning overflow in the Nix language | 16:42:25 |
| emily | IMO that part of the change was a mistake | 16:42:31 |
| emily | well, it would be just a difference of opinion if the negative values were handled consistently | 16:42:44 |
 jade_ | i don't know what it should do | 16:44:22 |
| jade_ | i chose to make it behave conservatively | 16:44:40 |
| emily | builtins.fromJSON "-9223372036854775809"'s behaviour is not conservative though | 16:46:56 |
| emily | see | 16:47:06 |
| emily | JSON has only one numeric type and we certainly want everything that fits in a Nix integer to be represented as one (because Nixpkgs expects that). so the two options are optimistically coercing JSON literals that look like Nix integers into Nix integers and leaving the rest as floats, or coercing JSON literals that look like any kind of integer into Nix integers, leaving ones that are clearly floats as floats, and rejecting the rest. currently, we do neither | 16:48:52 |
| jade_ | correct, I would class that as "a bug" | 16:49:20 |
| emily | I think the former is what makes the most sense per JSON semantics and the general behaviour pointed at by the RFCs. the latter is defensible too. but picking one for positive values and another for negative values because of how nlohmann_json interacts with C++ numeric types not so much | 16:49:22 |
| emily | ok. but I think it is hard to define these erroring semantics in a way that doesn't have weird edge cases wrt how JSON works | 16:50:09 |
| jade_ | I think that getting a float in nix in general because it's nix is usually an undesired outcome | 16:50:14 |
| emily | for instance, there are also JSOn literal floats that cannot be represented | 16:50:22 |
| jade_ | but alsoooo, often you want to passthru json | 16:50:26 |
| emily | * for instance, there are also JSON literal floats that cannot be represented | 16:50:26 |
| emily | FWIW, the Nixpkgs integer parsing functions specifically reject the non-integer case, as I said | 16:51:02 |
| jade_ | so it is probably reasonable to try to just tolerate any numbers as losslessly as possible and eat the weird edge case that it's a float if it's too big | 16:51:05 |
| emily | so returning floats does not make those behave spookily | 16:51:09 |
