| 14 Aug 2025 |
 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 |
| emily | further context for this is https://github.com/NixOS/nixpkgs/pull/433710 because it turns out that fromTOML is a total mess (working on a stack locally) | 16:56:05 |
| jade_ | i would like consistent behaviour with pos/neg integers ideally and i would rather it be a total function. so ya | 16:56:08 |
| emily | btw what's the intended way to update functional2 snapshots with a just-built Lix? | 16:57:29 |
| emily | PATH=build/… hacks? | 16:57:33 |
