> It's reasonable for non-coercing === to work on different types, but what
would a non-coercing + do with different types? It has to throw an error.

Ah, didn’t catch that you were talking about non-relational operators as
well. Assuming a strict `+` was still overloaded for string concatenation,
yeah, an error makes sense (whereas if numeric only, NaN might also be
considered a reasonable answer).

For strict `<`, etc, I think it would be unintuitive to get an error or to
have arbitrary type order. Rather I’d expect it to be false when the types
didn’t match, since, for example, the correct answer to both the questions
"is seven greater than an object?" and "is an object greater than 7?" is
"no". This would be consistent with the behavior of the existing
always-incomparable value, NaN, as well. That said, I think an error would
be better than having an arbitrary type order if those were the two choices.

On Thu, Apr 13, 2017 at 12:56 AM, felix <felix8a at gmail.com> wrote:

> On Wed, Apr 12, 2017 at 7:23 PM, Darien Valentine <valentinium at gmail.com>
> wrote:
> >> One common JS problem is NaNs ending up in unexpected places, and it's
> >> often difficult to trace back where they came from. Getting a type error
> >> instead of a NaN would be nice.
> >
> > I’m not sure this would help with that. NaN may be the product of
> coercion,
> > but NaN itself is a numeric value, and it can be produced without any
> type
> > coercion, e.g. `Infinity/Infinity`, `(-1) ** 0.5`, etc. And the `===`
> > operator is a strict, non-coercive comparison, but that doesn’t mean it
> > throws type errors.
>
> Mysterious NaNs in js are usually due to implicit conversion of random
> objects to numbers, not normal numeric computation.
>
> It's reasonable for non-coercing === to work on different types, but
> what would a non-coercing + do with different types? It has to throw
> an error.
>
> Non-coercing < might throw an error or use some arbitrary ordering of
> types. I don't have strong feelings about that.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170413/bf206e0e/attachment.html>

> It's reasonable for non-coercing === to work on different types, but what would a non-coercing + do with different types? It has to throw an error.

Ah, didn’t catch that you were talking about non-relational operators as well. Assuming a strict `+` was still overloaded for string concatenation, yeah, an error makes sense (whereas if numeric only, NaN might also be considered a reasonable answer).

For strict `<`, etc, I think it would be unintuitive to get an error or to have arbitrary type order. Rather I’d expect it to be false when the types didn’t match, since, for example, the correct answer to both the questions "is seven greater than an object?" and "is an object greater than 7?" is "no". This would be consistent with the behavior of the existing always-incomparable value, NaN, as well. That said, I think an error would be better than having an arbitrary type order if those were the two choices.