Re: Re: Strict Relational Operators

2017-04-12 Thread Darien Valentine
> 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,

Re: Re: Strict Relational Operators

2017-04-12 Thread felix
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

Re: Re: Strict Relational Operators

2017-04-12 Thread Darien Valentine
> 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

Re: Re: Strict Relational Operators

2017-04-12 Thread felix
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

Re: Re: Strict Relational Operators

2017-04-12 Thread T.J. Crowder
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

Re: Re: Strict Relational Operators

2017-04-12 Thread Michael J. Ryan
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

Re: Re: Strict Relational Operators

2017-04-12 Thread Darien Valentine
> 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

Re: Re: Strict Relational Operators

2017-04-12 Thread T.J. Crowder
> 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

Re: Re: Strict Relational Operators

2017-04-12 Thread Alexander Jones
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

Re: Re: Strict Relational Operators

2017-04-12 Thread T.J. Crowder
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

Re: Re: Strict Relational Operators

2017-04-12 Thread T.J. Crowder
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

Re: Re: throwif operator

2017-04-12 Thread Нурбек
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

Re: Re: Strict Relational Operators

2017-04-12 Thread Michael J. Ryan
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