Lix Development | 415 Members | |
| (Technical) development of Lix, the package manager, a Nix implementation. Please be mindful of ongoing technical conversations in this channel. | 139 Servers |
| Sender | Message | Time |
|---|---|---|
| 14 Aug 2025 | ||
| 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 | |
| "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 | |
since adding a .0 isn't really meant to change a number by the specced JSON semantics | 15:40:39 | |
and indeed builtins.fromJSON "1.0" is 1 | 15:40:50 | |
oh wait 1.0 also prints as 1 | 15:41:01 | |
ok never mind :) | 15:41:12 | |
| anyway my point is just that we should pick one. the current behaviour is incoherent | 15:41:27 | |
| 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 | |