> 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,
On Wed, Apr 12, 2017 at 7:23 PM, Darien Valentine 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
> 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
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 think this is a reasonable argument for being able to write
expressions with non-coercing operators, and this is why
FWIW, I think the next steps for this discussion are:
1. To hear from people whether they feel the need for these operations in
their everyday work. It's interesting, you so often hear people saying
"Always use `===`, not `==`!" with...fervor...but apparently strict
versions of the relational
That's part of why I suggested it... My mention of Object.* Was mainly that
it could defer to a common base class/constructor implementation for
comparison. And that a string and number implementation should be
provided...
I'm also good with having non-matching types return undefined while
> Personally I think `a < b` should just become a compile error if the
types are not number.
Breaking stuff aside, I think this is an important point. The fact that the
LT/GT operators do work on strings is a source of bugs. As with default
sort, I’ve seen code written a number of times where it
> Personally I think `a < b` should just become a compile error if the
types are not number. TypeScript?
I'm not following you. JavaScript variables don't have types, so it can't
become a compile-time error; and making it one would *massively* break the
web. (Yes, you can use TypeScript to get
Personally I think `a < b` should just become a compile error if the types
are not number. TypeScript?
If you want to also check that they are both number (that's surely what we
mean here and not that they are both string!) and return `false` if not,
that's a separable concern which should not be
Grr, there's always something. I forgot to mention that solving this with
functions is an option because short-circuiting isn't an issue, both
operands have to be evaluated by these relational operators anyway. So
unlike the motiviations for infix functions or macros or whatever, we don't
have
Very interesting stuff so far.
My take on some options, organized into sections:
* Solving it in userland
* Using symbolic operators
* Using functions
* Using non-symbolic operators
# Solving it in userland:
Anyone wanting strict relational operators today can readily give
themselves functions
Yes, throw expressions would be helpful to shorten if statements to
one-liner ternary operators. I agree with you.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Thinking on it... (Number|Object|String) .strict(Equal|Greater|Less...)
Methods (a, b) might be better... If either value isn't a match for the
bound type, it's a false, even if both sides are equal...
Ex,.
Number.strictEqual(null, null) false
Object.strictEqual(1, 1) false
...
If you're
13 matches
Mail list logo