Potential backwards compatibility issue with options bag

[mhofman]

One potential issue to consider is that the current spec ignores the reviver if it's not callable, so newer programs running on old engines might not get the behavior they expect. This is akin to adding a param that was previously ignored, but in this case the author might have different expectations.

[acutmore]

Thanks for highlighting.

I think the chance of code passing a non-callable value here that has the properties we look up relatively unlikely. Though hard to say for sure until we pick the names for the options.

[mhofman]

Also with an options bag approach we should approach whatwg to suggest adding a similar options bag to .json()

[erights]

think the chance of code passing a non-callable value here that has the properties we look up relatively unlikely.

That's relevant to the case of old code on new engines. I take @mhofman 's point to be about new code on old engines.

Under the proposal that we seemed to settle on in plenary today -- @bakkot's overloading on second argument being a non-callable object -- new code would pass non-callable objects in that position. When that new code is run on an old engine, the non-callable object in reviver position would not cause an error. Instead it would be ignored. For new code to adapt to possibly being run on old engines, it would need to feature test for this. Given the non-error behavior,

• such feature testing would be awkward
• if the feature testing is not done, then the code proceeds to silently do a wrong but similar thing, rather than cleanly terminating with an error.

Nevertheless, overall I still like what we settled on today. But we would need to alert people about this hazard. And eat the cost that much new code will nevertheless be written without awareness of this hazard. That's why we have generally avoided non-erroneous new-code/old-engine behaviors.

[acutmore]

Ah yes, sorry I hadn't fully absorbed both angles.

And where feature detection would be: Object.isFrozen(JSON.parse("{}", { toFrozen: true })) (or whatever the option name is).

[bakkot]

That's why we have generally avoided non-erroneous new-code/old-engine behaviors.

The core JS language has avoided this, but fwiw it is very common for hosts such as the web platform or node to add new options to existing options bags, and it's rarely a problem. Not that I disagree with your analysis, just to say that it's a very normal situation for almost all JS programmers.