Strict Relational Operators

[T.J. Crowder]

I've started a separate thread to discuss felix's idea of an expression
mode making all operators within it non-coercing (as it's rather more broad
than this topic):
https://esdiscuss.org/topic/strict-non-coercing-expressions

-- T.J. Crowder


On Thu, Apr 13, 2017 at 6:58 AM, Darien Valentine <valentinium at gmail.com>
wrote:

> > 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.
>>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170413/13f9db32/attachment-0001.html>