| 20 Mar 2026 |
 thubrecht | That "standard" also says
This specification allows implementations to set limits on the range and precision of numbers accepted
| 09:36:04 |
 raitobezarius | 8 bits integers | 09:39:30 |
| raitobezarius | max | 09:39:31 |
 KFears& 🏳️⚧️ (they/them) | https://seriot.ch/software/parsing_json.html | 09:42:26 |
| KFears& 🏳️⚧️ (they/them) | This is a very good overview of the JSON ambiguities and which parsers choose which behavior | 09:42:44 |
| KFears& 🏳️⚧️ (they/them) | Highly recommend for deciding which behavior is preferred | 09:42:54 |
 emily | I don't think there's any real reason to reject duplicate keys | 09:50:48 |
| emily | though I guess silently dropping the data is annoying. but numeric precision means that'll happen for some things anyway | 09:51:03 |
| emily | there's lots of terrible things about the JSON format but it's not invalid to have duplicates | 09:51:19 |
| emily | it's not builtins.fromIJSON | 09:51:45 |
 piegames | my main worry is that different implementations may handle it differently, which may lead to diverging Nix code behavior | 09:56:52 |
| emily | true. but aborting vs. handling it is also a difference in behaviour :) | 09:57:11 |
| piegames | Imagine one Nix implementation who always takes the first attribute, on that always takes the last attribute, and one that takes whichever based on some internal hashmap | 09:57:32 |
| emily | so unless there is existing divergence I wouldn't make it worse without reason | 09:57:34 |
| emily | yes, for sure. one of a million reasons there needs to be a spec | 09:57:52 |
| emily | but "imagine one Nix implementation that aborts" is just another possibility in that list too | 09:58:04 |
 Rutile (rootile) | Ah, so thats how we get language detection:
{"language": "cppnix", "language": "lix"}
| 09:58:14 |
| emily | it'd be interesting to see how pre-nlohmann 2.3 handled it though | 09:58:30 |
| emily | there's other divergences in JSON handling from 2.3 already | 09:58:36 |
| piegames | yes, but on a different domain. Given that aborts cannot be caught, you cannot produce two different Nix inputs that terminate with a different output value | 09:59:02 |
| emily | (but in practice 2.3 behaviour is just deprecated given that Nixpkgs doesn't support it any more and everyone has diverged from it) | 09:59:04 |
| emily | right, I agree that abort vs. not is the least bad kind of divergence | 09:59:26 |
| emily | it's going to be really annoying if you have an RFC-valid JSON document that you simply can't interoperate with from Nix just because it's weird/cursed though, if there is otherwise no divergence | 10:00:09 |
| emily | (and it's not possible to abort on every Nix behaviour that's weird enough that an implementation without a reference spec might get it wrong, because … it's load-bearing weird behaviours all the way down) | 10:00:35 |
| piegames | To be honest the root issue is with the RFC itself | 10:01:04 |
| piegames | even other libraries typically have an option "RFC compliant vs safe&sane", because for many applications, this is a security issue | 10:01:44 |
| KFears& 🏳️⚧️ (they/them) | In reply to @kfears:matrix.org
https://seriot.ch/software/parsing_json.html We would like to point again to this gem of a blogpost that dissects extremely well how many RFCs and versions JSON has and how much is left to be interpretation-dependent, so you could very easily be RFC-compliant and also diverge from other parsers in major and very painful and noticeable ways | 10:03:23 |
| piegames | Are there any other specifications of JSON other than that RFC? | 10:04:02 |
| emily | there are multiple RFCs | 10:04:47 |
| emily | and the original spec on json.org or whatever which is 100% useless | 10:04:55 |
