[eesmith]

https://en.wikipedia.org/wiki/JSON#Data_portability_issues :

> Although Douglas Crockford originally asserted that JSON is a strict subset of JavaScript, his specification actually allows valid JSON documents that are invalid JavaScript. Specifically, JSON allows the Unicode line terminators U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR to appear unescaped in quoted strings, while ECMAScript 2018 and older does not.

[empyrical]

That bit of incompatibility will be going away when this proposal is implemented, however:

https://github.com/tc39/proposal-json-superset

[v413]

It is already implemented in the current Firefox, Chrome and Safari 12.

[chubot]

Yeah I remember that quirk, and that's why I said it's "as much of a subset as it ever was". :) Because of this issue, it was technically never a subset.

But almost all real JSON documents are subsets of JavaScript, unless they happen to have those characters.

And the salient point is that if JSON never changes, then no further divergence from JavaScript is possible.

[eesmith]

But remember that your comment wasn't actually addressing avmich's objection to the assertion "All JSON is JavaScript, but not all JavaScript is JSON".

That assertion is indeed incorrect.

avmich then wrote "I thought they diverged specifications".

That is also correct. JSON was meant to be a perfect subset of JavaScript. Instead, and by accident, it diverged from the relevant specification.

Your comment instead was mostly focused on opposition to changing the existing JSON specification, which is a different topic.

[daveevad]

> JSON allows the Unicode line terminators U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR to appear unescaped in quoted strings, while ECMAScript 2018 and older does not.

My code has parsed a lot JSON and that is new data to me. Thank you for that!

Do you know the historical reasoning for this particular deviation? Are there any infamous bugs or common use cases this departure impacts?