deep-equal

NaN === NaN is false and Object.is(NaN, NaN) is true. A comparison about data takes the second: a caller holding two records that both failed to parse a number is holding the same record twice, not two different ones.

The other half of Object.is, and the half the ecosystem splits on: lodash and fast-deep-equal answer true, util.isDeepStrictEqual answers false. A refund that rounded away to nothing keeps the mark saying which way the money went - the same argument number/round@1 freezes one contract over.

The same rule one level down, because a rule that held only at the root would be a property of the entry point rather than of the walk.

1n == 1 is true and Object.is(1n, 1) is false. Two values a caller cannot add together are not the same datum, and the loose comparison is the one nothing here uses.

One is an object with a prototype and own indexed properties, the other is a primitive. typeof separates them and so does anything a caller does with them afterwards.

The first thing the spelling a caller reaches for gets wrong: comparing two JSON.stringify results answers false here, because a serialisation carries an order the data does not have.

The two are different to Object.keys, to in, and to a caller writing if ("a" in row). The JSON.stringify spelling answers true, because undefined is dropped on the way out.

Measured, four of six shipped implementations answer true here: they walk Object.keys, which does not report a symbol. Two objects whose data differs compare equal, and nothing about the call says so.

The prototype is part of what the value is: methods, a constructor and whatever else the class carries are all reachable from one and not from the other. Every implementation measured agrees, and inputDomain says in as many words that a caller who wants them equal wants a different function.

The same rule at the other end of the prototype chain, and the place the ecosystem parts again: lodash answers true, util.isDeepStrictEqual answers false. An object built to have no inherited toString is not the object that has one.

A comparison reads values, and reading a property is what a caller does too. The alternative - comparing descriptors - would answer about how an object was written rather than about what it carries, and would make a memoised object differ from its own plain copy.

Object.keys([,1]) is ["1"] and Object.keys([undefined,1]) is ["0","1"], so the two differ in what they hold and not only in what they read as. map and forEach skip the hole and visit the undefined, which is where a caller meets the difference.

Own keys are identical here and the lengths are 2 and 3, so this is the row that says the walk compares an array's length as well as its keys. Without it a table built only from key sets would pass an implementation that dropped the length check.

The sharpest instance in the catalogue of a silent wrong answer: measured, [email protected] and dequal/[email protected] both answer true, because a Set has no own enumerable property and a walk over keys sees two empty objects.

The same two implementations answer true here too, which is what separates this from the row above: it is not that they compare members badly, it is that they do not look at the collection at all.

The JSON.stringify spelling also answers true here, and for the same reason as the two above rather than a different one - a Map serialises as {}. Three ways of asking, one blindness.

A Map is compared by its entries and not only by its keys, which is the half an implementation comparing sizes and key sets would pass without.

Insertion order is observable on a Set - it decides iteration - and it is not part of what the Set holds. A caller who built the same set of ids from two different queries has one set of ids.

The other direction of the same blindness, and the one the ecosystem's remedy gets wrong: fast-deep-equal/es6 - the entry point its README sends a caller to for collections - answers false, because it tests membership with has, which is reference identity.

The same for a key rather than a member, which is the harder half: matching entries without an order means a key of one has to be found among the unclaimed keys of the other, and that is the only quadratic path in the contract.

A Date carries a number of milliseconds in a slot and has no own property at all. Two dates naming one instant are one datum.

The slot holds NaN, and the rule is the one the first group settles: Object.is and not ===. Measured, three of five shipped implementations answer false here, which is NaN's own trap arriving inside a built-in.

The neighbour of the row above, and the reason that row is about Object.is rather than about treating every invalid date as equal to everything.

The two things a pattern is. Everything else about a RegExp object is derived from them or is the state of a scan, which the last row of this group settles.

The half of the row above that says source is read.

The other half, and not the same claim: an implementation comparing only source passes the row above and fails here.

util.isDeepStrictEqual reads lastIndex and answers false; lodash, dequal and fast-deep-equal ignore it. This contract excludes it and the argument is not a show of hands. Measured: structuredClone(/a/g) with lastIndex at 3 returns a pattern whose lastIndex is 0, with source and flags identical, and the same for a sticky pattern. The declared domain is the values structuredClone carries and the admission oracle is that a value equals its own clone, so reading lastIndex would make this contract fail the oracle it was admitted on. util.isDeepStrictEqual is bound by no such domain; this contract is.

A row the author of this contract got wrong. A boxed number has no own property, so a walk that enumerates keys sees two empty objects and answers true - which is what this contract's own walk did, silently, until the dispatch was measured. lodash and util.isDeepStrictEqual were right about it all along.

The same slot blindness on a second kind, kept as its own row because a dispatch repaired for Number alone passes the row above and fails here - which is how the repair was checked.

The third kind, and the one that is easiest to leave out because Object(1n) is not a spelling anybody writes on purpose - which is exactly why a caller meets it through a library rather than through their own code.

The slots agree and the own keys do not. Measured, lodash answers true here - it reads the slot and stops - so this row is one of the two places this contract is stricter than the most-used implementation rather than looser.

A typed array has indexed own properties, so a key walk finds something - which is why this row passes almost everywhere and the next two do not.

Same bytes, different kinds, different lengths, and a caller cannot use one where the other is expected. The prototypes differ, which is what the walk reads.

The row that caught three of the five shipped implementations against the oracle: they compare elements with ===, so a float array holding NaN is not equal to its own structured clone. Object.is per element is the rule, and it is the first group's rule again rather than a new one.

The other half of Object.is inside a typed array, and the half an implementation comparing bytes would get right by accident - which is a different implementation from one that got the row above right.

An error caught and stored is a value like any other. stack is not read, because it names where the error was constructed rather than what it says, and two errors built at two call sites for one reason are one reason.

Measured, dequal answers true here - it walks own enumerable properties and message is not one of them. The same blindness as the collections, on the type a caller is most likely to be comparing when something has gone wrong.

cause is where the original failure is kept, so an implementation reading name and message alone answers true for two errors that happened for different reasons. It is compared as data rather than by identity, so a cause that is itself an object is walked.

The prototype rule of the second group, arriving where a caller most often branches on it: code that asks err instanceof TypeError is asking about exactly this difference.

Measured, three of six shipped implementations do not answer this at all - they exhaust the call stack. Answering is the claim; answering true is the second half, and it is the coinductive reading: two graphs that unfold to the same infinite tree are the same data.

The same claim through a collection rather than through a property, and it is not the same test: matching members recurses, so an implementation whose cycle detection lives only in the property walk answers the row above and never returns from this one.

The row that stops the one above from being satisfied by an implementation that answers true whenever it has seen a pair before. A cycle and a finite unrolling of it part at the first place the unrolling ends.

The row the author of this contract got wrong, in the hour after writing down the danger of cycle detection. The two Sets match either way round; also holds {v:1} against {v:2}. An implementation that memoises the pairs a failed candidate tried answers true, because the failed attempt left ({v:1}, {v:2}) marked as assumed equal. All four shipped implementations answer false, so this row founds no admission - what it founds is the clause, and the evidence for the clause is that the fault was committed here.

Since this was published: The two rows are correct rows - false is the answer, and every shipped implementation measured gives it - and they do not separate the defect their rationale names. The clause the contract states about speculation stands; what does not stand is that these two rows witness it. Nothing in this repository could have said so: a rationale is prose beside a correct answer, and only injecting the defect and watching nothing redden found it.

Measured at 3ec621c by injecting exactly that defect into this contract's own reference - the mutant object-deep-equal · DE-01, which replaces the line taking a pair back off the path with a no-op - and running it against the sound version over the four forms of the witness. The memoising walk answers false on this row and on and-answers-the-same-either-way-round, exactly as the sound one does. It answers true only when the keys are transposed and the right-hand also holds the very Set member the failed candidate tried; the witness these rows are built from holds a fresh object there, and the path is keyed by identity, so the pair the failed candidate left behind is never asked for again. The reading is of this reference and of no other: an implementation that memoises differently may well answer true here.

The same two values with their two keys declared in the other order, and nothing else changed. The walk that got the row above wrong answered false here, so a table carrying only one of the two would have been green on half the defect - which is what makes this a row rather than a note.

Since this was published: The sentence is true of this row and false of the pair. so a table carrying only one of the two would have been green on half the defect reads as though the two rows split the defect between them; measured, both are green on all of it. What the pair still does is what a transposition is for - it holds the answer steady under a reordering nothing should read - and that is a smaller claim than the one published.

The same reading at 3ec621c, and this row is wrong about its neighbour rather than about itself: the memoising walk really does answer false here, and it also answers false on the row above. Transposing the keys is one of the two things the separating form needs and this row carries that one; what it does not carry is the right-hand also holding the very Set member the failed candidate tried.

Nothing about a promise's contents is readable synchronously, so there is nothing to compare. false rather than a throw, because the caller asked a question with an answer: these are not the same value.

A WeakMap cannot be enumerated by design. Answering true for two of them - which the author's own walk did, because they have no own property - is the silent true this contract exists to refuse, arriving on a type nobody thinks to test.

Two functions are equal when they are the same reference and not otherwise: source text is not behaviour, and a closure carries what no reading of it shows. The author's walk answered true for these two as well.

structuredClone returns a plain object for a class instance - measured, the prototype goes from the class to Object - so the clone is not the same kind of thing. This row is what p1-reflexive-under-a-copy excludes rather than what it asserts, and it was found by fast-check on the first hundred draws while the property was being calibrated.

The same flattening at the other end: a null-prototype object clones to a plain one. util.isDeepStrictEqual answers false here too and lodash answers true, so the ecosystem is split on the row that decides how the oracle has to be stated.