Lix Development | 422 Members | |
| (Technical) development of Lix, the package manager, a Nix implementation. Please be mindful of ongoing technical conversations in this channel. | 142 Servers |
| Sender | Message | Time |
|---|---|---|
| 14 Aug 2025 | ||
IOW, the nlohmann_json semantics are "we try to find an integer type we can fit a literal into, and otherwise we produce a float" | 14:54:35 | |
if we were to implement "we try to find an integer type we can fit a literal into, and otherwise we produce a float" in Nix, we should produce a float for builtins.fromJSON "9223372036854775808" | 14:54:52 | |
otherwise, if we want "we reject integer-looking literals that don't fit into an integer type, and produce a float only for explicitly float-y values", we should error out on builtins.fromJSON "-9223372036854775809" | 14:55:16 | |
the current combination of behaviour seems like an unjustifiable accident caused by the impedance mismatch between nlohmann_json's API oriented around C++ numeric types, and Nix's signed-only integers | 14:55:45 | |
| P.S. I want to cry | 14:56:12 | |
| @raitobezarius:matrix.org please review https://gerrit.lix.systems/c/lix/+/3862 | 15:29:28 | |
In reply to @emilazy:matrix.orgThanks, I hate it | 15:34:14 | |
| well, blame JavaScript :) | 15:34:30 | |
| (and JSON for not specifying any goddamn semantics at all at first) | 15:34:35 | |
| Tbh if a library does untyped bullshit like that, I preferably want it out of my sight | 15:34:47 | |
| no, this is just JSON | 15:34:58 | |
| JSON has only one numeric type, because JavaScript does | 15:35:05 | |
| its type is even vaguer than JavaScript's however | 15:35:09 | |
| I don't have a strong opinion on "reject integer-looking things that are out of Nix integer range" vs. "always produce floats for things outside of Nix integer range"; both have their merits. the current state seems unjustifiable though | 15:35:36 | |
| i thought that JSON just didn't define any constraints on numeric types | 15:36:09 | |
In reply to @weethet:catgirl.cloudIn ~ 5 days, yeah | 15:35:52 | |
| and left that as an implementation detail | 15:36:25 | |
| it depends what you mean by "JSON". | 15:36:29 | |
| the original terrible specification defines syntax and says basically nothing about semantics at all https://www.json.org/json-en.html | 15:36:45 | |
| "A number is very much like a C or Java number, except that the octal and hexadecimal formats are not used." | 15:36:51 | |
| lolsob | 15:36:56 | |
| the latest RFC defines a single numeric type and says This specification allows implementations to set limits on the range Note that when such software is used, numbers that are integers and | 15:37:10 | |
| * the latest RFC defines a single numeric type and says
| 15:37:16 | |
| there is an RFC that subsets it into an interoperable subset that IIRC they say that IETF specifications SHOULD use; I believe it limits the range to the interoperable subset | 15:37:39 | |
| but I'd have to check | 15:37:42 | |
Nix could just always parse numeric literals in JSON into floats, but it would be annoying. (especially since Nixpkgs backs its integer-parsing functions by fromJSON) | 15:38:05 | |
In reply to @raitobezarius:matrix.orgThanks | 15:38:15 | |
| ok, I-JSON says
| 15:38:53 | |
| ok, Nixpkgs does in fact detect the float case for integer conversions | 15:39:36 | |
| so "fits into Nix integer → Nix integer, otherwise → float" would be desirable for Nixpkgs and consistent with other JSON implementations | 15:39:58 | |