| 20 Mar 2026 |
 emily | that was just a bad choice of colours | 10:18:28 |
| emily | anyway I don't think something called fromJSON should reject valid JSON unless there's truly no reasonable behaviour it could do with it | 10:19:01 |
 Qyriad | We agree | 10:19:14 |
| Qyriad | Python json.loads and jq both accept duplicate keys, with the last one winning | 10:21:25 |
 piegames | lol serde_json can't even detect duplicates | 10:27:05 |
| emily | isn't the serde model fundamentally event-based? I'd expect you can write a deserializer that detects them? | 10:27:53 |
| piegames | https://github.com/serde-rs/json/issues/1074 but also, this is the main reason why I hate "take the last value". It's bogus semantics, and on any input with duplicate fields the chances that it was generated in mistake is high. Taking the last value will lead to silent failure in such cases | 10:28:28 |
| piegames | it is possible with serde, and there is a PR, but currently serde_json offers no way to detect it | 10:28:54 |
 Coca | simd-json (the rust crate) seems to ignore duplication but keep the first one instead | 10:31:30 |
| Coca | nanoserde keeps the last one | 10:31:54 |
| * piegames sighs | 10:33:59 |
| piegames | I hate JSON so fucking much | 10:34:03 |
| piegames | currently reading the I-JSON spec and got painfully reminded that JSON has zero non-text handling capabilities | 10:34:37 |
 Sergei Zimmerman (xokdvium) | I recall there seemed to be some AWS endpoint that legitimately used duplicate keys too | 10:34:41 |
| Sergei Zimmerman (xokdvium) | Though I’m not sure I can find the reference now | 10:35:15 |
| piegames | let me rephrase the question, are there any reasonable use cases for duplicate keys where parsing both and then using only one of the values is the correct behavior? | 10:36:19 |
| emily | it's sorta like asking if there's any use case for parsing web pages with invalid HTML the same way everyone else parses them | 10:37:24 |
| emily | the use case is you can browse the web like everyone else | 10:37:36 |
| emily | the documents are dodgy from an interoperability/sanity standpoint, but when they exist in the wild and everyone treats them the same way in practice… | 10:37:55 |
| Qyriad | Unfortunately retaining only one of the values is arguably a more compatible behavior because the alternative is e.g. parsing them into a list, which is an entirely different type | 10:38:10 |
| emily | it's plausible you'd want the ability to get all the values of duplicated keys for some documents, but that's more in the territory of extending the language with more optional functionality than a reason to break stuff with the existing API | 10:38:32 |
| emily | yeah, an alternate API would probably have to wrap every value in a list, or realistically you'd potentially care about the order too in that case, so just to a parse tree with lists of key, value pairs | 10:38:58 |
| emily | but I doubt there's much demand for this | 10:39:04 |
| piegames | yes, the reasonable alternative would be to have JSON objects only exposed as multimaps … | 10:39:07 |
| Qyriad | serde_json even emits duplicate keys, fuck me https://github.com/serde-rs/json/issues/1074 | 10:39:33 |
| piegames | yes, that's why I said most duplicate keys are a sign of a mistake | 10:40:14 |
 KFears& 🏳️⚧️ (they/them) | In reply to @emilazy:matrix.org
yeah, an alternate API would probably have to wrap every value in a list, or realistically you'd potentially care about the order too in that case, so just to a parse tree with lists of key, value pairs Also could rename keys, like if you have duplicate key "a" it would become "a-0" and "a-1", but it's omega-cursed and also we think we have seen that in NixLang somewhere before | 10:40:26 |
| piegames | Murphy's law going strong there | 10:40:34 |
| Qyriad | Yeah, but parsing them into one value is likely to cause problems than parsing them into a composite structure | 10:40:53 |
| Qyriad | * Yeah, but parsing them into one value is likely to cause fewer problems than parsing them into a composite structure | 10:41:00 |
