Operator overloading revisited

[Christian Plesner Hansen]

> There are lots of subsets in the language already, this is a teaching and
> user preference outcome that we can't and shouldn't stop. Multiple paradigms
> and well-ordered subsets are not a problem, they are a success condition.
> But adding operators without considering first-class value types (==/=== and
> literal syntax) looks like a mistake.

This is the critical point.  Do you want operator overloading to
extend to classic objects (that is, instances of user-defined
functions) or to be restricted to the values/classes/types subset?
That's not as much a technical discussion but a question of design
philosophy.  I assumed that integration with the existing language was
desirable.  If not then the proposal is moot.

> No, because for two numbers a and b, a == b <=> a === b. In fact for any two
> values, (typeof a == typeof b && a == b) <=> a === b. If we want to support
> usable numeric and similar "scalar" type extensions, we might want to preserve
> this logic.

(I forgot to respond to this from a previous message)

What does "usable" mean?  If operators did work for classic objects
why not use them for scalars? There's === but I don't know why you
would want it to be anything other than object identity.  Is anybody
relying on (typeof a == typeof b && a == b) <=> a === b?