JSON.parseImmutable for creating Records and Tuples from JSON strings

  • By Ecma TC39
  • Last update: Nov 4, 2022
  • Comments: 2

JSON.parseImmutable Proposal


Stage 2


  • Robin Ricard (Bloomberg)
  • Rick Button (Bloomberg)
  • Nicolò Ribaudo (Igalia)
  • Ashley Claymore (Bloomberg)


This proposal complements the Records and Tuples Proposal. It was originally part of that proposal but split off into a separate proposal to reduce the scope of the core Records and Tuples proposal. #330

The problem being explored is ergonomic and efficient creation of a deeply immutable data structure from a JSON string.

JSON.parse(data, (key, value) => {
  if (typeof value === 'object' && value !== null) {
      if (Array.isArray(value)) {
        return Tuple.from(value);
      } else {
        return Record(value);
  return value;

Could be replaced with:





  • 1

    Naming bikeshed: "immutable"

    I think the word "immutable" is sufficiently overloaded that it'd cause confusion to use it.

    All primitives are immutable, but so are frozen objects without internal slots that have no "non-immutable object" properties.

    I'd love to gather suggestions of alternate names that can convey "produces Records and Tuples instead of Objects and Arrays" in a way that doesn't have nuances and edge cases. (I'll make my own suggestions in independent comments, as I come up with them, so they can be emoji-reacted to individually)

  • 2

    is JSON.parseImmutable significantly different enough that it deserves its own API?

    (copied from https://github.com/tc39/proposal-record-tuple/issues/330)

    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 https://github.com/tc39/proposal-record-tuple/issues/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?