Strict Relational Operators

[James Treworgy]

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.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/82222771/attachment-0001.html>