Kevin Smith wrote:
>
>
>     Your point about it being too late to salvage == (vs. ===) is
>     good, but perhaps with value objects plus further work to disable
>     implicit conversions, == will make a come-back -- but that's far
>     down the road.
>
>
> Work to disable implicit conversions?  Can you clarify?

It's a gleam in my eye, at least. Some day we may enable users to choose 
to get exception, not toString, on myUrl == "haha". Details TBD, and not 
via valueOf/toString hacking (which doesn't quite work).

> I'm actually quite wary (so far) of allowing the user to override an 
> operator whose abstract meaning is already so abstruse.

You've seen the rationale, here it is again:

== is overloadable along with < and <= to cope with unordered values and 
to enable common safe comparisons, e.g. 0m == 0.

!= and ! cannot be overloaded, to preserve De Morgan's Laws and other 
obvious invariants.

There is no "abstruseness" in x == y when typeof-types match. Even when 
they don't, for numeric types, the relationals and == are loose. We 
won't change that. Adding value objects should afford new numeric types 
the same expressiveness that number has, or usability impairments will 
hamper adoption.

If it's ok to test !0 or even 0 == "0" (yes, I know == is not transitive 
in full), then 0m == 0 or 0n == 0 should be supported too.

/be

Kevin Smith wrote:

> Work to disable implicit conversions?  Can you clarify?

It's a gleam in my eye, at least. Some day we may enable users to choose 
to get exception, not `toString`, on `myUrl == "haha"`. Details TBD, and not 
via `valueOf`/`toString` hacking (which doesn't quite work).

> I'm actually quite wary (so far) of allowing the user to override an 
> operator whose abstract meaning is already so abstruse.

You've seen the rationale, here it is again:

`==` is overloadable along with `<` and `<=` to cope with unordered values and 
to enable common safe comparisons, e.g. `0m == 0`.

`!=` and `!` cannot be overloaded, to preserve De Morgan's Laws and other 
obvious invariants.

There is no "abstruseness" in `x == y` when `typeof`-types match. Even when 
they don't, for numeric types, the relationals and `==` are loose. We 
won't change that. Adding value objects should afford new numeric types 
the same expressiveness that number has, or usability impairments will 
hamper adoption.

If it's ok to test `!0` or even `0 == "0"` (yes, I know `==` is not transitive 
in full), then `0m == 0` or `0n == 0` should be supported too.