JSON.parseImmutable as a separate companion proposal

[michaelficarra]

JSON.parseImmutable seems like it can be expressed as an option given to JSON.parse since it's otherwise identical as far as I'm aware. I see that in #74 it was originally imagined this way but quickly rejected. But couldn't we take an options bag in place of the reviver and branch on its type?

This kind of question is why I'm still a little uneasy about whether JSON.parseImmutable should be pursued as a follow-on proposal or not.

[ljharb]

It does seem like a separable piece that would be good in a follow-on proposal.

[nikeee]

There is also https://github.com/tc39/proposal-json-parse-with-source that might clash with adding a parameter to JSON.parse.

[gibson042]

That proposal does not change the JSON.parse ( text [ , reviver ] ) signature, just the arguments passed to a reviver function. So it would be possible to add another parameter like JSON.parse ( text [ , reviver [ , options ] ] ), or possibly to overload the second parameter to something like JSON.parse ( text [ , optionsOrReviver ] ) as in Temporal round methods and DOM APIs like addEventListener.

[acutmore]

Thanks for raising this. Have just discussed this with @littledan and @rricard. We are happy to split this off as a separate proposal, which will retain the stage 2 status. We can present this at the next plenary.

[acutmore]

new repo for anyone interested in following there 😀
https://github.com/tc39/proposal-json-parseimmutable