Strict Relational Operators

Thu Apr 13 12:35:26 UTC 2017

That would seem to make more sense. At the end of the day, for me, I just
don't much value in adding new syntax for operators to do this. The only
time I can think of in my own code where this would be useful (in the sense
that it would have avoided some extra type check to ensure things work as I
want) is evaluating >= 0, where the current Javascript behavior is
unfortunate:

*null >= 0 // true*
*undefined >= 0 // false*

But for most situations, it doesn't help much, you still need to do a
manual type check to avoid unexpected behavior. If I'm comparing a counter
to a limit, a loop might just run forever. If I'm comparing one thing to
another for sorting, it just puts all non-typed things first. The behavior
of many things will be different, but unlikely better. It doesn't help you
write code that avoids unwanted code paths.

I also feel like the problem of "are a and b of the same type, and is a
greater than/less than b" is very easily solved with a helper:

*if (strict.gt <http://strict.gt>(a, v)) {  }*
*if (strict.lt <http://strict.lt>(a, b)) { }*

What we REALLY need is runtime type checking. I write lots of code like
this (or using helpers to accomplish the same with less boilerplate) in
public APIs:

*function(a, b) {*
*    assert.ok(typeof a === 'number')*
*    assert.ok(typeof b === 'string')*
*    ...*
*}*

I don't see why we can't have a flow-like syntax that is syntactic sugar
for this:

*function(a: string, b: number) {*
*   let c: string[] = [a, 'foo']*
*}*

Yeah - different discussion - but I feel like addding indirect ways to
check types with new expression or operator syntax, rather than just
addressing the problem head-on by allowing runtime type checking at
variable declaration & function invocation time, is just going to further
confuse matters and make code quality and readibility worse, not better.

On Thu, Apr 13, 2017 at 8:04 AM, T.J. Crowder <tj.crowder at farsightsoftware.c
om> wrote:

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