Strict Relational Operators

Thu Apr 13 12:04:50 UTC 2017

Yeah. I suggested that if we aren't doing symbolic operators but rather
functions or something else, they should result in `undefined` for mixed
types, so you can differentiate if appropriate. (Symbolic operators like
`<=<` would need to be consistent with `===` and `!==`, though, which
don't, sadly, do that; and that won't be changing. :-) ) Functions or
non-symbolic operators would have the option of doing that, or throwing,
whatever people end up thinking is best.

-- T.J. Crowder

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

> Put another way  === is useful because you test for strict equality.
> Either it is or is not what you need. But always returning false when
> comparing things with less than or greater than doesn't ensure that you got
> what you want. A false value can be success as much as a true value.
>
> On Apr 13, 2017 7:37 AM, "James Treworgy" <jamietre at gmail.com> wrote:
>
>> Strict expressions. In the case of always returning false, that seems
>> like little help in avoiding bugs to me, since code flow always continues...
>>
>> On Apr 13, 2017 7:35 AM, "T.J. Crowder" <tj.crowder at farsightsoftware.com>
>> wrote:
>>
>>> James, are you commenting on felix's idea of strict expressions (in
>>> which case, I suggest the other thread: https://esdiscuss.org/topic/st
>>> rict-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.c
>>>> om> 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/574d7e0d/attachment.html>