tc39/proposal-array-equality

Determining Array Equality

proposal-array-equality's Issues

Promote to ArrayBuffer and TypedArray.

Can be promoted to ArrayBuffer and TypedArray?

Compare two ArrayBuffer / TypedArray byte-wise for equality.

Add a symbol to allow extending and modifying the equality check

I feel this is ripe for a symbol that allows extending and modifying the equality check. Library precedent is rather lacking (unless you consider Fantasy Land's Setoid spec and its implementers as precedent), but there is a common .equals idiom that's emerged that I've noticed.

For language precedent, it's pretty strong. Here's a few right off the top of my head:

• Java: public boolean equals(Object other)
• C++: boolean operator==(T other)
• Rust: std::cmp::Eq<T>, used by its == operator
• Haskell: Data.Eq

For naming, I propose Symbol.equals. This goes along with the idiom most are already using. And for standard library containers:

• Error objects: identical name and message and deep equal own expando properties. Stack should not be considered for the purposes of this.
• RegExp objects: identical pattern and equivalent flags (/gi and /ig are considered equivalent).
• Arrays: identical length and deep-equal entries, but ignore expando properties
• Maps: size is identical, each key of this is deep-equal with a key in other and their corresponding entries are also deep-equal
  • The idea is that these should be compared deeply in the same way objects are, just instead of string equality, it's deep object equality.
  • Algorithm note: I've tried to distill that into something sufficiently fast here. Either you'll need to encode similar in the spec or leave it implementation-defined for reasonable performance.
• Sets: size is identical and every key in this is deep-equal with a key in other
  • The idea is that these should be compared deeply in the same way objects are, just instead of string equality, it's deep object equality.
  • Algorithm note: I've tried to distill that into something sufficiently fast here. Either you'll need to encode similar in the spec or leave it implementation-defined for reasonable performance.
• Array buffers, shared array buffers, and array buffer views: equal byte data
• Promises: identical status and deep-equal value if settled, reference identity if pending

The default behavior should still of course be the standard algorithm, and it's left implied that types of course also need to be equal.

---

I could also see HTML wanting to hook into this as well:

• Event: detail deep-equal, eventPhase and mutable properties ignored, all other properties identical
• Node: children deep-equal
• Element: attributes and children deep-equal
• CharacterData: data equal
• Range: equivalent contents
• Request: equivalent target/headers/etc.
• And so on

Consider `Object.isEqual(a, b)` or similar instead

I feel very strongly that deep equality should be performed with a static function, not an array method or anything similar. Library and language precedent strongly argues in favor of this model:

• Lodash and Underscore: _.isEqual(a, b)
• Ramda: R.equals(a, b)
• Node's assert.isDeepStrictEqual's comparison function was factored out into util.isDeepStrictEqual after modules like deep-equal (10M downloads the past week as of today) and fast-deep-equal (27M as of today) took off.
• Clojure's =, Java's a.equals(b) method used practically everywhere as well as its java.util.Objects.equals that papers over the awkwardness with null, C++'s == behavior for all of its standard containers and wrappers, idiomatic std::cmp::Eq implementations in Rust, among many others.

Array-specific aspects: "empty" array elements, trailing `undefined`

JS Arrars have the weird quirk of supporting "empty" elements. For the most part, a = [0, , 2] behaves same as b = [0, undefined, 2] — both a[1] and b[1] are undefined — but there are observable differences, e.g. Object.values(a) is [0, 2] while Object.values(b) is [0, undefined, 2]!
This means that some definitions of array equality can not be reduced to "pair-wise element equality" someLogic(a[i], b[i]) — there is no JS representation of "empty" you could pass to someLogic.

Also, due to how JS ignores function arity mismatch by passing undefined, it's natural to wonder what the comparison will do on ['a', 'b', undefined] vs ['a', 'b']. Are different-length arrays where the extra trailing elements are all undefined considered different?
(IMHO they should not be equal, but I think it's important to say specifically as JS programmers might plausibly guess either way.)

I guess this should be informed by prior art in popular deep-equal libraries.

Path to stage 4!

Stage 4

• committee approval
• implement in two browsers
  • node
  • Chrome Canary / v8
    • Chrome (flagged)
    • Chrome (unflagged)
  • Firefox / SpiderMonkey
    • Firefox Beta
    • Firefox (unflagged)
  • Safari / Webkit / JSC
    • Safari (unflagged)
    • Safari Technical Preview
  • Edge / Chakra
    • Edge (unflagged)
  • TypeScript
  • Hermes
• ecma262 PR approved
• prepare ecma262
• merge test262 tests
• write test262 tests

Stage 3

• committee approval
• spec editor signoff
• spec reviewer signoff
• receive implementor feedback

Stage 2

• receive developer feedback
• committee approval
• spec text written
• spec reviewers selected

Should this really be deep?

My intuition differs here, and so does precedent in most other languages with dedicated array-oriented operators: https://github.com/isiahmeadows/es-stdlib-proposals/blob/master/proposals/array/equals.md

For deep matching, restricting it to just arrays seems like a very bad idea IMHO. Here's a concept I made for that, generalized to all values: https://github.com/isiahmeadows/es-stdlib-proposals/blob/master/proposals/value-matching.md