Native Equality Support for Structs

[musicq]

Currently, since struct instances are sealed, there is no built-in mechanism for native deep equality checks.

This limitation often requires developers to rely on helper functions like deepEqual to compare objects based on their data rather than their references.

const a1 = {name: "a", school: {grade: 1}}
const a2 = {name: "a", school: {grade: 1}}

deepEqual(a1, a2)

While this works, certain scenarios make implementing deep equality challenging. For example, in React, dependency arrays ([]) in hooks like useEffect rely on strict reference equality (===). If an object is passed directly without ensuring it retains the same reference, the behavior can become unpredictable:

const person = {name: "a"}

useEffect(() => {
  console.log(Math.random()) // // This runs unexpectedly if `person`'s reference changes
}, [person])

In cases like these, the lack of a native equality mechanism for struct instances increases cognitive overhead and complicates development.

Proposed Solution

If struct could natively support deep equality checks, it would significantly reduce the mental load for developers, particularly in scenarios where strict reference equality is not practical or desired. For example:

struct Person {
  constructor(name) { this.name = name; }
  name;
}

const a1 = new Person("a")
const a2 = new Person("a")

assert(a1 === a2)

Benefits

• Improved Developer Experience: Reduces the need for custom deep equality functions.
• Enhanced React Usability: Simplifies dependency tracking in hooks by ensuring consistent behavior with structured data.
• Cleaner Code: Avoids unnecessary boilerplate or workaround patterns to achieve expected equality checks.

[acutmore]

Struct fields are writable. Two separate struct instances can't be === referentially equal because either of them could be modified, so they need to remain separate instances.

const a1 = new Person("a")
const a2 = new Person("a")

a1 === a2; // needs to be false
a1.name = "b";
a1 === a2; // because this must be false

[musicq]

I see. Seems like it's hard to support deepEqual for structs🤔

[streamich]

This should be a new quadruple equals operator ====.

[mhofman]

I opened #62 to discuss a declarative way of initializing fields, allowing them to be declared read-only.

[extremeheat]

Maybe revisiting adding something like Object.compare(a, b) would be a good idea. It'd be helpful for comparing unsealed objects too.

[musicq]

Maybe revisiting adding something like Object.compare(a, b) would be a good idea. It'd be helpful for comparing unsealed objects too.

Maybe we can introduce a new hidden method like [Symbol.compare] which allow user to override how === works.

This can be a built-in method for struct so that it can do struct a === struct b.

[ljharb]

There is no way operator overloading would ever get consensus, especially for === which must never become fallible.

[irfanstract]

Maybe some sort of syntax, like (either) const struct Person (par with TypeScript's as const) or readonly struct Person or case struct Person, to opt-in to immutability and automatic value-based equality/identity (Object.is).