| 20 Mar 2026 |
 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 |
| emily | it's unlikely JSON documents people produce solely for consumption in Nix will have duplicate keys because most language APIs won't do that | 11:29:07 |
| emily | Lix accepting escaped NUL codepoints in JSON that correctly-written Nixpkgs library functions violate their contract on is far more likely to cause interoperability issues than duplicate keys tbh | 11:30:11 |
| emily | (and that's a case where there actually is current and historical divergence, so a warning would be much more justifiable there...) | 11:30:58 |
| emily | interesting to see simd-json diverge, though it also has several correctness issues open on GitHub, some from years ago 😅 | 11:34:00 |
| emily | wonder if they somehow get better perf from that result or something | 11:34:38 |
| emily | are you sure it's not storing both values in a parse tree type form and the lookup is just terminating on the first one actually? | 11:35:18 |
| Coca | My hunch was that simd-json can get the earliest acceptable value and then stop parsing, at least with the tape Value, but I would have to see | 11:35:49 |
| emily | oh I guess it's the same serde type(?) | 11:36:05 |
| emily | ah I see | 11:36:08 |
| Coca | its not the same serde type to be clear tho | 11:36:30 |
| emily | yeah if it's looking up from a string rather than parsing into a full DOM that makes sense | 11:36:31 |
| emily | also means it'll happily eat up a ton of invalid documents... | 11:36:43 |
| piegames | Unfortunately, this is not possible because of impurities, I was told | 11:36:57 |
| piegames | I already had the idea of having the whole bytecode interpreter run in sync with the old interpreter for verification purposes, and unfortunately that's not possible | 11:37:26 |
| emily | I'm not sure what you mean | 11:37:31 |
| emily | well for full interpretation sure | 11:37:42 |
| emily | not for JSON parsing | 11:38:18 |
