Should returned objects have a `null` prototype?

[peetklecha]

The return value for Object.grouBy, the groups property on arrays returned by String.prototype.match, and objects returned by JSON.rawJSON all have null prototypes. Should objects returned by JSON.parseImmutable also do this?

One argument raised at a recent TC39 was that since prototypes are mutable, having a null prototype (or some kind of exotic frozen prototype) would be necessary for these returned objects to be truly frozen. On the other hand, it seems like a non-starter for Arrays returned by this function to have anything other than the normal Array prototype.

[acutmore]

Note: For R&T it was also the case that only Record was being considered to have a null prototype.

The rationale being that it is possible to access Lists safely by first checking the type and then the length. And also that it's extremely useful to have list operations methods on Arrays/Tuples - a Tuple with a null prototype would not have been very ergonomic.

For the "deeply frozen" value returned from this proposal. If code checks for Array.isArray first it then knows it is safe to read .length as that will be an own property, and then it will know it is safe to read the properties that are length > P >= 0 as these will also all be own properties. So even though it has a prototype, this mutability can be avoided reliably.

The same argument can be made for non array objects returned from this proposal, if code checks Object.hasOwn first before reading a key that it can avoid Object.prototype. Though this is maybe a less common pattern that checking .length on arrays.

[ljharb]

then it will know it is safe to read the properties that are length > P >= 0 as these will also all be own properties

note that this is not the case for sparse arrays, although it'd be the case for anything new.

I think a null prototype for non-list-like objects is pretty important to have.

[acutmore]

note that this is not the case for sparse arrays, although it'd be the case for anything new.

Yeah, thankfully JSON parse never produces sparse arrays AFAIK

[gameroman]

note that this is not the case for sparse arrays, although it'd be the case for anything new.

Yeah, thankfully JSON parse never produces sparse arrays AFAIK

Only if you use the reviver function

[acutmore]

Makes sense. I think we'll be quite restrictive about what the reviver function can return for this proposal so that the final value can be treated as "deeply immutable" (for some definition of that term).

[peetklecha]

We have decided to make this question configurable via an options bag, although there is still an open question: should frozen: true imply nullPrototype: true?

My preference is yes. We could also throw if frozen: true but nullPrototype: true is not provided; alternately we could allow users to selected frozen: true, nullPrototype: false.

[ljharb]

for objects, i'd say yes - but for arrays, i'd say no