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/ > 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 <[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]> >> 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
