TC39 General
2025-04-10
plaintext logs
prev next
source on github
11:59
<Jack Works>
https://github.com/tc39/ecma262/issues/3563
11:59
<Jack Works>
found this when re-implementing RegExp in engine262
12:36
<Seokho Song>

I think between below the following tests in test262 are contradictory.

  1. https://github.com/tc39/test262/blob/main/test/staging/sm/class/superPropDelete.js
  2. https://github.com/tc39/test262/blob/main/test/language/expressions/delete/super-property-uninitialized-this.js

And I guess the spec-compliant way is 2, because the ReferenceError exception will be occur by the spec - "envRec.[[ThisBindingStatus]] is uninitialized" before accessing the property.

If it is, I'll open PR soon to test262. correct me if I'm wrong :)

12:47
<Jack Works>
maybe it's related to https://github.com/tc39/ecma262/pull/2267
20:18
<Mikhail Efanov>

Hey everyone! I had an idea to propose adding a native deepEqual to ECMAScript. I’ve written a small draft here: https://github.com/misha98857/proposal-object-deep-equal/blob/main/README.md, but I wanted to ask how relevant this idea might be — and whether similar proposals have been made and rejected before?

The main goal is to move away from third-party libraries and custom solutions in favor of built-in functionality.

20:29
<bakkot>
the idea is tossed around occasionally. it is a very large problem space; there are many different notions of what it would mean to be "equal". if you want to make the case for it you should give motivating examples for why someone would want to do this (in the browser - things which are mainly useful in tests are not good candidates to add to the language).
20:30
<Michael Ficarra>
we really need a deep equality section in https://github.com/tc39/faq
20:30
<ptomato>

hi, welcome! and thanks for taking the time.

about the idea, I've heard people say that there are many possible semantics for deepEqual which are all valid depending on what your use case is. some are mutually exclusive. not sure how widespread this view is in committee. anyway, as a starting point I'd suggest making sure you've catalogued all the different semantics that people might possibly expect from a deepEqual function and come prepared with arguments why a standardized one should choose one semantic over another.

also see the Composites idea which is on the agenda for the upcoming TC39. there is a Composite.equal function which would not exactly be deepEqual, but might cover some of the use cases

20:37
<bakkot>

as to prior art, there's been one actual proposal (https://github.com/tc39/proposal-array-equality) although it didn't go anywhere; you can probably find it in the notes for more.

there's also

and others I'm sure

20:39
<Mikhail Efanov>
Thanks. I hadn't seen this proposal before. It seems similar — two composite objects are almost equal, like in "common" deepEqual logic
20:41
<Michael Ficarra>
also related is [structuredClone](https://developer.mozilla.org/en-US/docs/Web/API/Window/structuredClone) which has made a decision on some of the "deep" questions
20:45
<Chris de Almeida>
also: https://github.com/tc39/proposal-record-tuple#equality
21:30
<littledan>
yes but still, this is different from what you typically want in a test framework, to check whether two mutable arrays are (currently) equal. Such a function does not have that same stability property. So probably multiple things need to exist.
22:06
<jschoi>

as to prior art, there's been one actual proposal (https://github.com/tc39/proposal-array-equality) although it didn't go anywhere; you can probably find it in the notes for more.

there's also

and others I'm sure

Hemanth H.M, ljharb, and I talked about reviving proposal-array-equality a few years ago but none of us have had time.
22:14
<jschoi>
(Also, there were https://github.com/sebmarkbage/ecmascript-shallow-equal, https://es.discourse.group/t/native-deep-clone-algorithm/, and the dormant https://github.com/tc39/ecma262/issues/2555.)
22:24
<jschoi>
Also, I recall someone in the Committee saying once that we probably will never ever be able to add anything to Object.prototype ever again without breaking websites. Does that apply to static methods in Object?
22:27
<shu>
it was more about Array.prototype than Object.prototype
22:27
<shu>
static methods are fine
22:27
<bakkot>
this is also true of Object.prototype to be clear
22:28
<shu>
fair, i would also object to adding stuff to Object.prototype
22:28
<shu>
even if it's web compatible it's guaranteed to be a bugfarm or security thing
22:46
<jschoi>

My feedback is that your proposal looks like a good start. Were I writing this proposal, I would make sure I do three more things:

  1. Search thoroughly for similar official TC39 proposals, like proposal-array-equality, find the meeting notes when they were presented to the Committee in the meeting notes repository, and determine the biggest barriers to them advancing. Other than the lack of time of the champions. If you want to try to revive any proposal you find, feel free to open an issue and start working on the next steps.
  2. Search for more prior art of deep equality in JavaScript as practical—particularly popular deep-equality NPM packages. (Examples of deep equality in other languages also is good, but JavaScript has big differences from all other languages.)
  3. Compare the behavior of the prior art (maybe in a table). Do they compare objects’ enumerated properties, use symbol-based protocols, or do something else?
  4. Investigate how real-world codebases use the prior art—particularly popular NPM packages depending on the popular deep-equality NPM packages. I would be especially interested to find out whether those popular dependents on deep-equality packages use deep equality only in testing or for production code.

For example, if you find that virtual-DOM libraries often use certain types of deep equality in hot loops, that could be a compelling-enough argument to add to the JS engines.

This would all be volunteer work, of course, and we know how thankless volunteer work can be. It must have been a lot of hard work for you already. Thank you for taking the time.