| 20 Mar 2026 |
 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 |
| emily | I-JSON defines a restricted format for interoperability | 10:05:01 |
| KFears& 🏳️⚧️ (they/them) | It could make sense to refer to the behaviors and quirks of the currently used JSON parser directly and state outright "this is what we're working with", and roll back behaviors back to that baseline if changing the parser impl | 10:05:04 |
