Strict Relational Operators

[James Treworgy]

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/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
>>
>>
>
> _______________________________________________
> 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/9dd33741/attachment.html>