Strict Relational Operators

[T.J. Crowder]

James, are you commenting on felix's idea of strict expressions (in which
case, I suggest the other thread:
https://esdiscuss.org/topic/strict-non-coercing-expressions), or strict
relational operators?

Other than felix's strict expressions, I don't think anyone was suggesting
that strict relational operators should throw. It would be important that
they behave consistently with `===` and `!==`: Just result in `false` when
the types don't match.

-- T.J. Crowder


On Thu, Apr 13, 2017 at 12:29 PM, James Treworgy <jamietre at gmail.com> wrote:

> I am of the opinion that this isn't really a worthwhile effort in the
> context of a non-typed language. There are several issues.
>
> First, it doesn't actually create any parity with ===. Triple equals never
> throws an error, it just returns false if the types are unequal. These
> constructs would change the way the language works fundamentally in that an
> expression can cause an error which it currently cannot.
>
> Second, it really just provides a kind of "too late" poor man's type
> checking. What you really wanted was a guard when the variable was created
> or the argument passed.  It may provide little help about the actual source
> of the bug.
>
> New syntax and the complexity it creates seems a high price to pay for a
> little band aid.
>
> If we were going to add some simple syntax to try to help this problem
> without going full typescript/flow then I'd be much more in favor of simply
> adding type guard clauses to function arguments that are evaluated at
> runtime.
>
>
> On Apr 13, 2017 2:44 AM, "T.J. Crowder" <tj.crowder at farsightsoftware.com>
> wrote:
>
>> 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/st
>> rict-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
>>>
>>>
>>
>> _______________________________________________
>> 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/6020c16e/attachment-0001.html>