Hello!
I would like to discuss a draft RFC that adds two independent and opt-in
flags to ext/json for PHP 8.7:
- JSON_ALLOW_COMMENTS
- JSON_ALLOW_TRAILING_COMMAS
Both flags would be accepted by json_decode() and json_validate().
Strict JSON would remain the default. Comments are limited to // and
non-nesting /* ... */ at JSON whitespace boundaries. Trailing commas
permit one comma after the last element or member of a nonempty array or
object.
The implementation processes comments in the existing re2c scanner. It
handles trailing commas in the existing Bison grammar. It does not
preprocess or copy the input, so it preserves strings and original
source locations. The RFC uses two primary votes so that either
extension can be accepted independently.
Draft implementation is located here: <https://github.com/php/php-
src/pull/23336>
Recently I also published a similar PHP library:
https://github.com/otar/jsonc
I would particularly appreciate feedback on the API names and the
inclusion of json_validate(). Feedback on the specified UTF-8, control-
character, and error-location behavior would also be useful.
Otar
Hello!
I would like to discuss a draft RFC that adds two independent and
opt-in flags to ext/json for PHP 8.7:
- JSON_ALLOW_COMMENTS
- JSON_ALLOW_TRAILING_COMMAS
Both flags would be accepted by
json_decode()andjson_validate().
Strict JSON would remain the default. Comments are limited to // and
non-nesting /* ... */ at JSON whitespace boundaries. Trailing commas
permit one comma after the last element or member of a nonempty array
or object.The implementation processes comments in the existing re2c scanner. It
handles trailing commas in the existing Bison grammar. It does not
preprocess or copy the input, so it preserves strings and original
source locations. The RFC uses two primary votes so that either
extension can be accepted independently.Draft implementation is located here: https://github.com/php/php-src/pull/23336
Recently I also published a similar PHP library: https://github.com/otar/jsonc
I would particularly appreciate feedback on the API names and the
inclusion ofjson_validate(). Feedback on the specified UTF-8,
control-character, and error-location behavior would also be useful.Otar
Does this essentially mean JSON5 support? If so, just call it that. (I am undecided on the best way to support that.)
--Larry Garfield
Does this essentially mean JSON5 support? If so, just call it that. (I am undecided on the best way to support that.)
--Larry Garfield
That is a language known as Microsoft's JSONC or Nigel Tao's JWCC (JSON
with Comments and Commas) they are effectively equivalent. JSON5 would
also require single quotes, unquoted keys, NAN and +/-INF values,
multiline strings, and some other minor stuff I don't even remember
--
Anton
Hi
That is a language known as Microsoft's JSONC or Nigel Tao's JWCC (JSON
with Comments and Commas) they are effectively equivalent
I think this proposal makes sense and with regarding to Otar's questions
regarding naming, I think a single JSON_ALLOW_JSONC flag to allow both
comments and trailing commas would be the best option. If there's an
existing, reasonably widely accepted standard for that, we should just
reference it and not add separate flags that result in a combinatorial
explosion.
Best regards
Tim Düsterhus