Strict Relational Operators

[James Treworgy]

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