| 19 Mar 2026 |
 raitobezarius | In reply to @sky1e:mildlyfunctional.gay
Shall I file an issue then? Please do so | 23:48:25 |
| 20 Mar 2026 |
 sky1e | https://git.lix.systems/lix-project/lix/issues/1162 | 00:10:00 |
 thubrecht | Looking at the previous json parser, it also silently ignored duplicates and kept only the last value | 09:01:28 |
| thubrecht | https://github.com/NixOS/nix/blob/0baf7dc25e0a5fcd25dcd9d9cb737c682d01e4e7/src/libexpr/json-to-value.cc#L69-L92 | 09:01:59 |
 delroth | https://www.rfc-editor.org/rfc/rfc8259#section-4 "The names within an object SHOULD be unique." not "MUST", so a parser should support duplicate keys anyway | 09:26:35 |
| delroth | though the RFC also says "lol it's unpredictable what parsers will do and some throw errors" | 09:26:59 |
| delroth | what a great RFC | 09:27:04 |
| raitobezarius | i want to cry | 09:29:59 |
 K900 | But JSON fits on a business card! | 09:30:31 |
| K900 | Or something | 09:31:25 |
| delroth | the business card: "100 microsd cards taped to each other" | 09:31:36 |
| 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 |
