| 20 Mar 2026 |
 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 |
| Qyriad | We should almost definitely at least warn on this though | 10:41:10 |
| piegames | hm, as in, runtime warning? | 10:41:30 |
| Qyriad | Yes | 10:41:37 |
| piegames | fucking hell | 10:44:41 |
| piegames | there is a rust crate called ijson | 10:44:45 |
| piegames | which has nothing to do with I_JSON, and is just "an opinionated fork of serde_json by a person whose name starts with i" | 10:45:12 |
| Qyriad | Of course | 10:45:32 |
 Coca | All the rust json crates I already know of:
Input: {"name": "One", "name": "Two"}
serde_json (serde API): Err(Error("duplicate field `name`", line: 1, column: 22))
serde_json (Value API): Ok(Some(String("Two")))
nanoserde: Ok(Test { name: "Two" })
facet-json: Ok(Test { name: "Two" })
simd-json (serde API): Err(Error { index: 0, character: None, err_type: Serde("duplicate field `name`") })
simd-json (Value API): Ok(Some(Value([String("One")])))
| 10:46:07 |
| piegames | "internet json" surely wins the prize for the least searchable name of the week | 10:46:08 |
| Coca | * All the rust json crates I already know of:
Input: {"name": "One", "name": "Two"}
serde_json (serde API): Err(Error("duplicate field `name`", line: 1, column: 22))
serde_json (Value API): Ok(Some(String("Two")))
nanoserde: Ok(Test { name: "Two" })
facet-json: Ok(Test { name: "Two" })
simd-json (serde API): Err(Error { index: 0, character: None, err_type: Serde("duplicate field `name`") })
simd-json (Value API): Ok(Some(Value([String("One")])))
| 10:46:15 |
| piegames | "cause fewer problems" as in "fail less loudly and prominently" | 10:47:01 |
| piegames | also what the fuck on them having different behavior based on which API you use | 10:47:40 |
| piegames | can we collectively please all go back to XML already? | 10:48:11 |
| Coca | yeah its certainly something | 10:48:37 |
| Coca | actually argh I could be more clear here with serde_json since Value is still parsed using serde traits in serde_json, but in simd-json the Value API is wholly separate from serde | 10:51:33 |
 emily | btw I would very strongly caution against doing this without an extremely comprehensive test suite and probably carefully directed fuzzing. it is likely to cause far more "no abort, different results" interoperability issues than duplicate keys ever would. 2.4 switching to nlohmann was part of why it was probably the most hash-breaking release in memory | 11:22:54 |
| emily | see also toml11 bumps sleepwalking into breaking Nixpkgs lib tests etc. | 11:23:20 |
| emily | any complete of builtin parser implementation like that should most likely come with a period of running both of them and aborting on any divergence | 11:24:03 |
| emily | (how many hours do you have to learn about XML interoperability issues?) | 11:25:26 |
| emily | (it's a miracle Nix at least only has it as an output format) | 11:25:40 |
| emily | (and I like XML!) | 11:25:46 |
| emily | I really don't think so. the JSON iceberg is not the Nix iceberg | 11:27:26 |
| emily | a warning about input you don't control is not actionable or going to go anywhere, unless it's a truly unfixable interoperability problem | 11:28:29 |
