Simple Array Destructuring shouldn't require use of $jscomp

[arciisine]

When using a very simple destructuring pattern, it should be possible to convert this to simple assignments. Reading the spec, http://www.ecma-international.org/ecma-262/6.0/#sec-destructuring-assignment, I can see why the definition of $jscomp is what it is, but it seems like overkill for simple assignments.

Given the input:

function add(a) {
  let [b,c] = a;
  return b+c;
}

add([1,2])

I would expect the output to be something along the lines of:

function test(a) {
  var b = a[0], c = a[1];
  return b+c;
}

test([1,2])

Instead, what I'm seeing is:

/* $jscomp definition */;
function add(a){
   var b=$jscomp.makeIterator(a);
   a=b.next().value;
   b=b.next().value;
   return a+b
}
add([1,2]);

[brad4d]

Destructuring is supposed to work for any iterable. We cannot assume at compile time that the thing being destructured is an array.
When we move type checking before transpilation, this would be possible, but I don't see the benefit being worth the added code complexity.

[arciisine]

I would strongly disagree. From a performance standpoint, a[0] vs $jscomp.makeIterator(a).next().value would have a huge impact. Especially if you are running the code often.

Essentially I'm having to optimize around this, by skipping destructuring altogether due to the performance implications of how this is handled.

[brad4d]

Destructuring is a programmer convenience.
I expect it's slower than equivalent non-destructured code even when run natively instead of transpiled.
I don't believe it's necessary for us to make it super efficient, when there's a simple workaround of just not using it in time-sensitive code.

@dimvar, what is your opinion?

[dimvar]

For now, I agree there isn't much we can do. I think it's probably worthwhile to optimize this when transpilation moves after type checking. I'll reopen and make it low priority.

[Dominator008]

This is similar to #1584.