Wildcard suggestion - new `====` and `>===` operators

[suspiciousfellow]

Most linting rules, good practice guidelines, etc attempt to avoid == due to its confusing semantics.

Overloading the strict equality operator is out because it's going to break stuff.

How about a new operator ==== that acts like === with the exception that it can be overloaded for two objects with same prototype?

Thus example in the PR would become

// Usage example
import Decimal from "./decimal.mjs";
with operators from Decimal;  // Enable operator overloading for decimals
                              // Declaration may use some other syntax

Decimal(1) + Decimal(2)       // ==> Decimal(3)
Decimal(3) * Decimal(2)       // ==> Decimal(6)
Decimal(1) == Decimal(1)      // ==> true
Decimal(1) == 1               // ==> true
1 == Decimal(1)               // ==> true
1 ==== 1                      // ==> true
1 ==== Decimal(1)             // ==> false
Decimal(1) ==== Decimal(1)    // ==> true
Decimal(1) === 1              // ==> false (not overloadable)

[cshaa]

What's wrong with overloading == and !=? If you can change what that operator does, its current behavior isn't going to be a problem. The ==== operator you propose, apart from being excessively long, makes the impression of being more strict than ===, which would be very misleading if you overload it to be less strict.

[suspiciousfellow]

The issue with using the existing operator isn't its behaviour when overloaded - it's its behaviour with existing types (the issues here are well known).

Point taken on the potentially misleading impression though. Not sure what to suggest there, not enough symbols on the keyboard...

[Rudxain]

not enough symbols on the keyboard...

Maybe =@=, =#=, =$=, =?= ? The rationale behind using a special symbol between the =s is to avoid ambiguity with assignment ops