Tab Atkins Jr. (2013-07-19T19:21:25.000Z)
On Fri, Jul 19, 2013 at 1:21 PM, Rick Waldron <waldron.rick at gmail.com> wrote:
> On Fri, Jul 19, 2013 at 1:35 PM, Tab Atkins Jr. <jackalmage at gmail.com>
> wrote:
>>
>> On Thu, Jul 18, 2013 at 4:34 PM, Andy Earnshaw <andyearnshaw at gmail.com>
>> wrote:
>> > It's potentially a breaking change, because
>> >
>> > 0 < 1 < 1
>> >
>> > evaluates to false in current implementations because
>> >
>> > (0 < 1) < 1
>>
>> Luckily, this is false in the chained operations too, since "(0 < 1)
>> && (1 < 1)" evaluates to false.
>>
>> One problem is that in current Javascript, the equality and the
>> comparison operators are at different precedence levels.  Python puts
>> them at the same level, so that chaining can be purely left-to-right.
>> There's a decent chance that code does indeed depend on this, due to
>> testing equality of a comparison with a bool (which is stupid, but
>> people do it).
>
> While this is all true, the simple answer is:
>
> var a = 1, b = 2, c = 3;
> a < b < c; // true
>
> is already valid JavaScript and can't be co-opted to express new runtime
> evaluation semantics.

Well, that's a bad example, because it's true with chained operators
too.  Let c = 1.5, though, and you get different behavior.

This type of code is broken in the first place, though.  Are we
assuming that it's prevalent enough to cause problems?

~TJ
forbes at lindesay.co.uk (2013-07-24T05:13:00.641Z)
Well, that's a bad example, because it's true with chained operators
too.  Let c = 1.5, though, and you get different behavior.

This type of code is broken in the first place, though.  Are we
assuming that it's prevalent enough to cause problems?