I guess this would require operator overloading. Is there a proposal for that? A JavaScript version of numpy/pytorch would also need overloading (plus array slicing).

Is there any non-primitive JS type that has non-referential equality for ==?

Yeah, that's one of the core problems, there's no overloading of equals in JS and no other cases of objects using non-reference equality. Adding that in itself would be a big deal (ex. see the Records and Tuples proposal which has been going on for years and may never complete)

There's exactly one IIRC. document.all

Why not just use 'String()' or '2020-01-01'?

Temporal includes `equals` methods on every type. String comparison sometimes works, but there are enough cases where it doesn't (especially when comparing strings that refer to the same data but were generated by different libraries so formatting is different for things like trailing zeroes of decimals, time zone aliases, etc.) that it's usually best to use a library function for comparison instead of just using string comparison.

Comparison functions are unlikely to work across libraries too?

It looks like `.epochMilliseconds` should work as a Map/Set key/member in some situations, though you'll need to preserve the instant in the value in the Map case if you want to preserve the zonedata / do further operations on the Instant.

For the Set case you could use a Map{v.epochMilliseconds:v} and preserve the Instant.

Not great, but I think we all blame JS for this rather than Temporal. This could be made to work by the runtime but then polyfills would fail.

Passing Dates to a React component caused re-rendering issues in some of my applications due to Date being an object.

I had to resort to numbers (Unix time) to not have to add memoization everywhere. Seems like this will continue with Temporal. Or React-Compiler will solve this.

Because it is impossible in JS? Except some crazy hacks, similar to how Java's constant string pool works, where every used object is a reference to a value in a pool of all objects.

I wouldn’t call this a particularly crazy hack, it’s also called string interning and I reckon that’s what every language runtime does when strings are immutable (which includes javascript runtimes, also this isn’t required by the language specification).

There is the record and tuple proposal. If we'd have methods on records (currently not part of the spec) this would be trivial.

Even if that worked, using these in a map/set would be a lot like using floating point numbers in a map/set - which is generally a bad idea.