| 14 Aug 2025 |
 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 |
| emily | also, I don't think this should be a major consideration, but I suspect that making the negative case error out with nlohmann_json would be a pain | 16:51:33 |
| emily | because it is already a float by the time you see it, because of being a value that does not fit into the integer types | 16:51:59 |
| emily | I mean I guess you can compare the float but float precision issues may make that weird | 16:52:13 |
| emily | and you have to determine whether it "could be" an integer | 16:52:20 |
| emily | let's put it this way | 16:52:35 |
| emily | if we were going to hard-reject JSON integer values | 16:52:40 |
| emily | it should be based on the -(2^53)+1 to (2^53)-1 interoperable range | 16:53:09 |
| emily | and happen on the serialization end as well | 16:53:18 |
| emily | (IMO) | 16:53:22 |
| emily | that would be undesirable though because of fromJSON being abused for general integer-parsing | 16:53:32 |
| emily | so we're already outside the bounds of the fully interoperable JSON format | 16:53:44 |
| jade_ | also fromJSON may take some json that isn't actually getting operated on in nix except for rearrangement (e.g. the large integers don't actually get touched) | 16:54:05 |
| emily | well, the large integers will still get clobbered precision-wise | 16:54:23 |
| emily | that's sort of inevitable though | 16:54:32 |
| emily | and why people who put large integers into JSON put them in strings generally | 16:54:42 |
| jade_ | yes, i just mean that they had it coming to a degree; having any json parsing error out is unfortunate | 16:54:52 |
| emily | Nixpkgs just does the funny thing because of Nix's lack of useful parsing functions | 16:54:53 |
| emily | right | 16:54:56 |
| emily | I will probably prepare a revert of that fromJSON change in the absence of strong objection / someone who wants to try and make it do the same for negative integers | 16:55:24 |
| emily | I wish someone had told Douglas Crockford what semantics are | 16:55:39 |
