JSON cannot be a subset of JavaScript

[erights]

In reforming the JavaScript treatment of \u2028 and \u2029, we frequently described the rationale as ensuring that JSON is a proper subset of JavaScript. Indeed, this brings it much closer. But we cannot repair the remaining discrepancy:

[{"__proto__": []}]

As JavaScript, this makes a singleton array whose element inherits from an empty array. As JSON, this makes a singleton array whose element inherits from Object.prototype and has an own data property named __proto__ whose value is an empty array.

Because of this, JSON will forever only approximate a subset of JavaScript.

[erights]

FWIW, I put an array on the outside to avoid the issue that JSON is approximates a subset of the JavaScript expression grammar, which is distinct from any JavaScript start production.

[devsnek]

I feel like the "subset" part is about syntax, not runtime behaviour.

[erights]

I feel like the "subset" part is about syntax, not runtime behaviour.

If language X's syntax is a subset of language Y's syntax, but X and Y associate these with, say, completely different meanings, I would say only "X's syntax is a subset of language Y's syntax."

A language consists of a lot more than syntax.

[erights]

This misunderstanding --- which I shared --- caused https://github.com/Agoric/SES/issues/147

We should avoid over-simplistic statements that lead people to write buggy programs.

[bakkot]

I wonder how often code actually uses "__proto__": rather than __proto__:.

Out of historical interest, is there a reason this syntax was not restricted to sloppy mode? At least for the quoted case?

[erights]

I don't recall ever considering making a strict / sloppy distinction here.

Attn @allenwb Do you remember?

[allenwb]

Out of historical interest, is there a reason this syntax was not restricted to sloppy mode?

Because TC39 decided that proto in an object literal was the de factor standard for declaratively setting its [[Prototype]] and there is no point in ever inventing some other syntax. Applies to both strict and sloppy.

We potentially could have excluded recognizing stirng literal "proto" as special. But I don't think at the time anybody ever brought it up as a JSON subset issue. We did exclude computed property names.

[ljharb]

Is there any chance it would be web compatible to exclude the string literal form now, even if just in strict mode?

[devsnek]

given that the consistent quotes eslint rule exists, i'd assume it will break at least a few sites.

[claudepache]

FTR, the incorrect assumption that JSON is a subset of JS has led to implementation bug in some JS engine: https://bugzilla.mozilla.org/show_bug.cgi?id=1337564

[erights]

given that the consistent quotes eslint rule exists, i'd assume it will break at least a few sites.

Does the consistent quotes rule complain about

{__proto__: ...}

?

[kumavis]

@erights i believe this the rule, includes examples https://eslint.org/docs/rules/quote-props#consistent

[gibson042]

proposal-json-superset was careful to describe the post-change language as a syntactic superset of JSON for precisely this reason. The semantic discrepancy was explicitly mentioned and survives in the definition of JSON.parse as "extended PropertyDefinitionEvaluation semantics defined in B.3.1 must not be used".

What would make that more clear?

[claudepache]

What would make that more clear?

The problem does not come from what is said, but from what is not said.

There is a note in the spec (precisely at the end of this section) stating that “valid JSON text” is a subset of ES PrimaryExpression syntax. It should be added that nevertheless, such a text, when interpreted by JSON.parse() or when interpreted as ES PrimaryExpression, does not always produce the same value.