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 <[email protected]> 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" <[email protected]> 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" <[email protected]> >> 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 <[email protected]> >>> 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" <[email protected] >>>> 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 < >>>>> [email protected]> 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 <[email protected]> wrote: >>>>>> >>>>>>> On Wed, Apr 12, 2017 at 7:23 PM, Darien Valentine < >>>>>>> [email protected]> 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 >>>>>> [email protected] >>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> es-discuss mailing list >>>>> [email protected] >>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>> >>>>> >>>
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
