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/strict-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
