Discuss
  • Fwd: Fix Left-Associative Compound Conditional Statements!!

Fwd: Fix Left-Associative Compound Conditional Statements!!

# Joseph Groseclose (9 years ago)

Left-Associative Compound Conditional Statements

I would like the ability to compare many values in compound. As I do not see any real reason to avoid this, here is my proposal:

Following this document (thanks @wykatz)

What problem are we solving:

Often, it makes it easier and more convenient to compare values in a range as opposed to comparing one to another and that value to even another. In order to avoid this, JavaScript could add the ability to "chain" many comparators, failing after the first inequality that is falsy.

Provide Non-Trivial Example Code Showing the Problem:

For the remainder of this issue/request, I will be using (almost exclusively) the "<" comparator, but any normal operators should work with this proposal, including but not limited to:

  • ==
  • ===
  • >
  • <
  • > =
  • <=
  • yada yada yada (not an operator)

Two examples:

let foo = 1,
    bar = 2,
    baz = 3;
if (foo < bar && bar < baz) {
    // ...do something!
}

While vaguely trivial, this snippet demonstrates the easiest way to accurately compare these three values in a basic conditional. We have to compare either the first two values and the second to values serially or in parallel.

Likewise (and slightly less trivial):

let arr = [ 'foo', 'bar', 'baz' ];
for (var i = 0; i < arr.length; ++i) {
    // do something...
    if (i > 1) {
         break;
    }
}

The above illustrates an example where we want to iterate in a range. There are several solutions to this (including a compound condition in the for statement, cloning and slicing, or reversing the array and setting i greater than zero), but this is even less convenient than the original example!

Show How the Example Code is Improved With the Proposal:

Now, we only have two left-associative conditions to evaluate as opposed to three

let foo = 1,
    bar = 2,
    baz = 3;
if (foo < bar < baz) {
    // ...do something!
}

We have saved ourselves the trouble of including a good deal of logic in our simple for loop as well:

let arr = [ 'foo', 'bar', 'baz' ];
for (let i = 0, y = 2; i < arr.length < y; ++i) {
    // do something...
}

What are Alternate ES3 (or ES5) Solutions to the Same Problem?: I've included some solutions to how this can be avoided, it is worth noting in this section that this is not so much about this situation being unavoidable so much as it is a matter of convenience.

Actually, scratch that, its not even JUST a matter of convenience. A simple evaluation in your developer console will tell you that this currently evaluates inconveniently (I am avoiding the term "incorrectly" here because it is not theoretically incorrect if we consider these evaluations left associative):

1 < 2 < 3 // true where...
true < 3 // true...because
+true // 1
1 < 3 // true

Bear in mind that this is not a catch-all definition of this behavior:

false === false == false // false (wut?)

If the Proposal is For New Syntax, What if Anything Does it Desugar To?

The desugaring is shown above, but the concatenation of conditionals can be converted into their non-concatenated equivalents:

(1 < 2 < 3) === (1< 2 & 2 < 3) // Not a typo

If New Syntax, Can it Be Compiled to ES3 (or ES5)?

Absolutely, in the same way it has been outlined above

Does the Proposal Change any Existing Semantics?

I'm not entirely sure this is semantic (because the comparators of any two values should evaluate in the same way they always have), but it is worth noting in this section that any two values should work with compound conditionals, not just numbers. For example,

[] == [] === []

should fail comparison.

I realize this effectively makes === a silver bullet in compound conditional statements, but I can't see any other way this would work.

Please let me know if there is any more context or detail I can provide, or whether there are considerations I have not made.

# Kevin Smith (9 years ago)

Actually, scratch that, its not even JUST a matter of convenience. A simple evaluation in your developer console will tell you that this currently evaluates inconveniently (I am avoiding the term "incorrectly" here because it is not theoretically incorrect if we consider these evaluations left associative):

Since this proposal would change the semantics of existing valid programs, it would be a breaking change. And breaking changes aren't really "allowed" (breaking the web and all that).

# Joseph Groseclose (9 years ago)

Isn't this logic theoretically broken? If any existing code is using it, the code that is using it is probably performing an invalid or inaccurate operation and therefore this would only break that code so much as it was already not functioning as expected?

# Till Schneidereit (9 years ago)

On Thu, Sep 24, 2015 at 4:50 PM, Joseph Groseclose <jgrosecl49 at gmail.com>

wrote:

Isn't this logic theoretically broken? If any existing code is using it, the code that is using it is probably performing an invalid or inaccurate operation and therefore this would only break that code so much as it was already not functioning as expected?

There are many examples of code that doesn't really do what the author thought it does, but just so happens to do what's required to produce a correct result in combination with other, potentially equally "incorrect" code. "Fixing" the logic here would mean breaking the overall program.

# Claude Pache (9 years ago)

For an old discussion on the same subject, see:

esdiscuss.org/topic/chained-comparisons-from-python-and-coffeescript

# Joseph Groseclose (9 years ago)

At some length I see, heh. Alright, I guess that just about sums it up.

# Isiah Meadows (9 years ago)

I think the main issue with this idea, based on that thread, is the burden of proof it won't break the Web. No one seems to have actually tested it, yet. I don't know of any obfuscators that emit that from a transform (they only emit it if that was in the input), so my heuristic is that it likely won't break 90% of sites, but even then, 10% of the Internet broken is still far too breaking.

Also, as a side note, -1 on the exclamation points for the subject.

# Joseph Groseclose (9 years ago)

I'm not even sure it goes so far as that. Most likely those currently attempting to sue this syntax have realized that it is relatively inconsistent for non-truthy values and given up, but the sentiment (I suppose) is that even the sub-1% that are actually using this in a live/production setting are too many to break.

Also, I've never in my life apologized for punctuation indicating appropriate levels of excitement, but I did try and edit the title and found myself incapable of doing so. So, if anyone who has control over the ability to edit this site is reading this or anyone knows who I can contact to normalize the title, know that I would prefer it be changed.

# Isiah Meadows (9 years ago)

To be honest, the best way to see is to make a custom "fixed" build of a browser and test it out. It's easy to implement with desugaring.