Proposal for new floating point and integer data types

Tristan Zajonc tristan at
Tue Oct 29 10:51:10 PDT 2013

On Tue, Oct 29, 2013 at 10:04 AM, Brendan Eich <brendan at> wrote:

> Tristan Zajonc wrote:
>>     if (mutMatA == mutMatB) {
>>         accidentallyMutate(mutMatA);
>>         assumeStillEqual(mutMatA, mutMatB, data);
>>     }
>> Is this bug related to operator overloading?  It seems just the nature of
>> the beast with mutable reference types. Pretty much all JS matrix libraries
>> today use:
>> if (mutMatA.equals(mutMatB)) {
>>     accidentallyMutate(mutMatA);
>>     assumeStillEqual(mutMatA, mutMatB, data);
>> }
>> which I assume would suffer from the same bug?
> You bet, but special forms exist to have primitive semantics, which can be
> meta-programmed only in certain ways (we try to preserve certain
> invariants). With .equals, anything goes. With == where both operands are
> object references, there has been an invariant. Allowing operator
> customization to break that invariant might be worth the downside, but it
> deserves discussion.
Got it, worthy of discussion. My user data point is that I've never assumed
== has that invariant. Overloading equals is a bigger deal, but it's not
clear users should expect invariance given existing toString/valueOf
issues.  So +1 for this not being a blocker to extending your operator
proposal more broadly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list