Discuss
  • Non-binding destructuring assignment

Non-binding destructuring assignment

# Elie Rotenberg (10 years ago)

Using array destructuring assignment and constraining linting rules, I often find myself having to chose names for bindings I don't intent on using. I usually end up using a conventional ignore name, such as _ignore, which I "void" to shut up the linter without adding exceptions. Besides the linting problem (which can be solved by refining the linting rules), it's still a conceptually useless binding.

Here's a contrived example:

const lastOfThree = ([first, second, third])  => third;

Which I usually end up rewriting:

const lastOfThree = ([_ignore1, _ignore2, third]) => {
  void _ignore1;
  void _ignore2;
  return third;
}

This problem doesn't exist when using objects, since only the fields specified on the LHS are bound.

I realize the bigger topic behind non-binding match is refutable pattern matching, as per strawman:pattern_matching, but being able to dismiss a matched (or unmatched) value from a destructuring assignment seems a very often desirable feature when programming in a functional style (eg. working with lists represented as 2-element arrays). Most functional-style languages have a non-binding matching feature.

This topic has been discussed in the following topics:

Does anyone else feel the need for a specific means of dismissing a binding from a destructuring assignment? Is pattern matching still on discussion?

# Sebastian McKenzie (10 years ago)

The binding identifiers are optional. You can do what you want already with:

const lastOfThree = ([,, third]) => {
  return third;
}
# Elie Rotenberg (10 years ago)

Wow, thanks. I feel dumb for asking :D

# Andreas Rossberg (10 years ago)

I agree that we should have wildcard patterns. I also think that array elisions are a non-solution, because you need a magnifier to read or count them, and they square oddly with optional commas in the end.

# Brendan Eich (10 years ago)

Andreas Rossberg wrote:

I agree that we should have wildcard patterns. I also think that array elisions are a non-solution, because you need a magnifier to read or count them,

Agree.

and they square oddly with optional commas in the end.

Old rule: allowing one (and only one) comma at end for maintainabilitiy does not make an elision. For that you need a comma at the front or two commas adjacent in the middle. Ok, odd but old too (ES3), and your "commas" plural oversold it :-P.

# Tab Atkins Jr. (10 years ago)

On Wed, Apr 29, 2015 at 4:39 AM, Elie Rotenberg <elie at rotenberg.io> wrote:

Using array destructuring assignment and constraining linting rules, I often find myself having to chose names for bindings I don't intent on using. I usually end up using a conventional ignore name, such as _ignore, which I "void" to shut up the linter without adding exceptions. Besides the linting problem (which can be solved by refining the linting rules), it's still a conceptually useless binding.

Honestly, this should probably be answered by fixing the linter, so it doesn't give linting errors when a variable named _ is unused. (In fact, it should probably do the opposite, and give a lint error when _ is used. This'll make users of underscore or lo-dash unhappy, though. ^_^)

# Rick Waldron (10 years ago)

Why _? A linter can just allow the end developer to define the binding name.

jshint/jshint#2352

# Tab Atkins Jr. (10 years ago)

Of course. _ is just a common name for the "i don't care" destructuring slot.