Destructuring declarations that bind nothing should probably be an early error

[allenwb]

In the ES6 spec., there is no check that a destructuring let/const/var actually introduces any bindings.

For example:

let ;

is a syntax error, but (updated 10/22/15)

let { } = obj;

is valid syntax that does nothing (it doesn't add any new variable bindings).

There are reports that some ES6 developers are encountering bugs cause by complex destructing patterns that unintentionally don't introduce any bindings.

This seems like a design bug in ES6. It would be trivial to specify that this is an early syntax error.

In 13.3.1.1
LexicalBinding : BindingPattern Initializer
- It is a Syntax Error if the BoundNames of BindingPattern has no elements.

In 14.1.2
FormalParameter : * BindingElement*
- It is a Syntax Error if the BoundNames of BindingElement has no elements.

Note that this is a breaking change for any program that actually contains such empty binding patterns. So there is some risk to making this change.

[bterlson]

On the surface fixing this bug seems like something we could get away with while there are no interoperable destructuring implementations. Nice find!

[nzakas]

Oops, just sent an email to esdiscuss before I saw this. Yay! :)

[bterlson]

@nzakas thanks much for pointing this out :) Definitely file bugs for any other issues you find!

[bterlson]

@allenwb what about non-binding forms (AssignmentPattern and friends)? Should [] = [] be an error? I say so...

[bterlson]

I also note that let {} and let [] are syntax errors at least since the initializer is not optional.

[getify]

I have strong concerns about this proposal:

1. I have on two occasions already had the need (during debugging, etc) to do things like this:

   var {
   // x,
   // y
   } = foo();

   ...where I comment out different parts of the destructuring declaration, and in some cases even comment out all of them.

   It would really suck if this practice of commenting them out during debugging and dev would work only while there was at least one left uncommented, but if I needed them all commented out, I'd have to re-arrange the code by commenting out the entire destructuring pattern part, but (for example) maybe still need to call the foo().

   In that scenario, this seems at best surprising and at worst rather hostile.

2. What about array destructuring? Will this proposal disallow this?

   var [
   // a,
   // b
   ] = foo()

   ... in the same way? Or what about?

   var [ , , ] = foo()

   ...if you have a stateful iterator on an array arr, you may want to do:

   var [ , , ] = arr;
   
   // later
   var [x, y] = arr;

   ...where you're expecting the [ , , ] to basically advance the stateful iterator by two steps, such that x and y are assigned from positions 2 and 3, respectively.

It sounds nice to assume that { }, [ ] and [ , , ] destructuring patterns are mistakes by developers, but that's just not a safe assumption.

Since @nzakas has already landed a linter rule for eslint for catching these things, I think that is the better path. Let tooling catch/warn about these, but don't make the language prevent these potentially not-mistake cases.

[rossberg]

I disagree with this proposal. It creates an irregularity and makes life harder for code generators, but also for people who want to comment out parts of a pattern. I don't think there is any real win either. Moreover, as Brian pointed out, destructuring without a RHS is an error already.

[nzakas]

I think [] = [] should definitely be an error.

Another scary pattern is this:

let { loc: [] } = foo;

@rossberg-chromium this isn't just about variable declarations, there are also assignments. You'd still be able to comment out parts of a pattern, just not every part at once. You're also missing this use case completely:

let { foo: {} } = bar;

@getify I'm having a hard time understanding why commenting out every property at once is useful for debugging. Isn't this:

var {
// x,
// y
} = foo();

The same as:

// var {
// x,
// y
// } = foo();

?

[caitp]

Isn't this:

var {
// x,
// y
} = foo();

The same as:

// var {
// x,
// y
// } = foo();

?

The RHS is evaluated before the binding pattern is walked, so foo() is still invoked, regardless of whether any bindings are created

[nzakas]

@caitp yes, but unless you're relying on side effects, that difference is inconsequential.

[nzakas]

Assuming goes both ways. :)

In any event, inability to comment out code just the way you want it doesn't seem like it should be a blocker for this. We all have editors, most have shortcut keys for inserting comments. If you need to use two keystrokes instead of one to help prevent unnecessary errors that are hard to find, that seems like a good tradeoff (IMHO). You can always move the RHS of an assignment to the next line temporarily and get the same effect.

[getify]

intentional side effects sometimes are as important but yet benign as console.log statements inside foo(), again for debugging purposes.