| 15:19 | <Aapo Alasuutari> | I've been interested in doing more struct-of-arrays type of JS coding recently, and there a TypedArray.equals check might be useful at times... Though I don't have a direct use case at hand. |
| 17:17 | <kriskowal> | The question of standardizing deep equality begins with the question, “which deep equality?”, since it is not a problem that generalizes well. I think there’s an opportunity to introduce a protocol that looks like: [Symbol.equals](other, childEquals=Object.is, seen=new Map) but if I were holding my breath, I would have died ten years ago. |
| 17:20 | <kriskowal> | This is the direction I would go because it doesn’t require the standardization of one deep equality with a name like Object.equals or Reflect.equals, but does allow for any kind of transitive equality, including shape validation, including graphs with cycles. |
| 17:22 | <kriskowal> | And progress on such an effort could begin with a ponyfill. I am fond of how Python’s operators like len close over all the behavior of intrinsics and defer to to a “protocol” only when the type passes no known “brand check”. That would allow the language to evolve under the ponyfill. And it’s not a big ponyfill. |
| 18:55 | <bakkot> | even equality of TAs is tricky to define (at least for the float ones) because of NaN |
| 18:56 | <bakkot> | equality of ABs is at least straightforward, and there's a reasonable performance case for doing it natively (i.e. it can be implemented as memcmp) |
| 18:58 | <bakkot> | I have been kind of kicking around the idea of adding more built-in comparators, so could do arrayOfNumerics.sort(Number.compare) or .sort(Compare.numeric) or whatever, and an AB comparator could live there I guess |
| 18:59 | <bakkot> | (https://es.discourse.group/t/proposal-idea-descending-sort/889/7) |
| 19:02 | <kriskowal> | Clearly, .sort(Number.negate.compose(Number.compare)) #tdz |
| 20:07 | <gwen> | even equality of TAs is tricky to define (at least for the float ones) because of NaN |