3 ms·

Because noone wants to dump a ton of work into a JSON parser they can't say is standards-compliant because it also supports C-style comments?

• whoisthemachine 5y ago
  Hm it is interesting that your hypothesis is solely the exclusion of comments from JSON. I can understand the constraint when you consider JSON as a data transmission spec rather than a configuration spec. I also find TOML to be much a cleaner syntax than either of the two, but maybe we should just give up and make a JSON-C (for Configuration, I just made this) which supports comments.
  • hathawsh 5y ago
    FWIW, JSON5 and Hjson share those goals. https://json5.org/ https://json5.org/ https://hjson.github.io/ https://hjson.github.io/
  • samatman 5y ago
    Or just use TOML when it's appropriate; that's what I do, and I haven't had cause to regret it. One can usually answer the question "am I going to frequently have deeply-nested tables and/or long strings for keys" in advance, and if the answer is no then TOML is practically ideal. If it proves to be wrong occasionally than JSON is a reasonable fallback, as is just coping with the verbosity of TOML.
  • nigeltao 5y ago
    See JWCC (JSON With Commas and Comments) https://nigeltao.github.io/blog/2021/json-with-commas-comments.html https://nigeltao.github.io/blog/2021/json-with-commas-commen...
  • chris37879 5y ago
    I'm not sure if it comes from a plugin or not, but that's one of the options I have in VSCodes language dropdown, JSON with comments, and it's exactly what the name says, it's json, but it doesn't die on // style comments. It also kicks in if I name the file with .jsonc as the extension.