See https://nigeltao.github.io/blog/2021/json-with-commas-comments.html
for more information.
It is quite common to have trailing commas in JSON, and a lot of
parsers support it. I believe this could be trivially supported by
PHP, even if you skip adding support for comments.
Perhaps this could be disabled by default and made opt-in with a
option flag? json_decode already supports passing in options.
Is there any interest in this?
See https://nigeltao.github.io/blog/2021/json-with-commas-comments.html
for more information.It is quite common to have trailing commas in JSON, and a lot of
parsers support it. I believe this could be trivially supported by
PHP, even if you skip adding support for comments.
This is certainly one of the more reasonable proposals for extended JSON
I've seen - much better than throwing the kitchen sink at it like JSON5,
for instance.
However, as that page makes clear, there are dozens of similar proposals
out there, so I'm not sold on why PHP should jump on this particular
one. It's not clear who is currently using it, or if there's actually a
formal definition outside that article.
Perhaps this could be disabled by default and made opt-in with a
option flag? json_decode already supports passing in options.
The risk is that this opens the gate for a complex set of "quirks flags"
like the referenced Wuffs library. As the article you linked says:
Wuffs has 20 JSON quirks so far. As always, there are trade-offs.
They’re not free (in terms of maintenance cost) and have super-linear
complexity: that file’s comments also has 12 call-outs to the subtleties
of combining two particular quirks.
I would really love for one of these conservative supersets of JSON to
become a widely-adopted, formal standard, and would then welcome native
PHP support. But unless and until that happens, I think this is too much
of a minefield.
Regards,
--
Rowan Tommins
[IMSoP]
See https://nigeltao.github.io/blog/2021/json-with-commas-comments.html
for more information.
...
Perhaps this could be disabled by default and made opt-in with a
option flag? json_decode already supports passing in options.The risk is that this opens the gate for a complex set of "quirks flags"
like the referenced Wuffs library
I'm not against making changes to JSON parsing, but you're right about
complexity, it can cause issues, especially if the JSON string is coming
from an un-trusted source, e.g.
https://labs.bishopfox.com/tech-blog/an-exploration-of-json-interoperability-vulnerabilities
{
"description": "Duplicate with comments",
"test": 2,
"extra": /*, "test": 1, "extra2": */
}
Is this comment a problem (parse error), ignored so 'test' is set to 1
(assuming the duplicate key is allowed and the value is replaced), or
handled as a comment so 'test' remains with the value 2?
Craig