First add an options objects parameter to JSON.stringify and JSON.parse

[allenwb]

This proposal is one of many tweaks that could be made to JSON.stringify/parse to make them more versatile. But many of them need to be opt-in either for backwards compatibility or because they are not always applicable. This could be worked around by added additional stringify/parse methods with new names but that is a very heavy weight approach.

A better approach is to added additional control parameters to stringify/parse.

Note that the current semantics for the second parameter to both methods only recognizes function or native Array objects. All other objects passed in that position are ignored. That means that it would be backwards compatible to revised their specification to accept an options object as the second parameter. Such an option object should be defined to have option properties corresponding to the existing positional options.

As the first step in enhancing stringify/replace I think you should specify such an option object invention and then use it for opt-ins to new functionality or breaking changes.

[mathiasbynens]

Having to opt-in to sensible defaults would be much less useful than just fixing the current behavior. Still, this could be an alternative if the current proposal doesn’t work out.

[mathiasbynens]

Just to clarify, JSON.parse doesn’t need any changes with this proposal.

The idea to add an options bag to JSON.stringify was discussed during today’s TC39 meeting and there was consensus that, for this particular proposal, fixing the default would be better.