Extensible destructuring proposal

Domenic Denicola d at domenic.me
Tue Jul 21 13:09:54 UTC 2015

For maps you can just do

const [[k1, v1], [k2, v2], ...rest] = map.entries();

There is no need to add more complexity to object destructuring (which should only be used for objects and their string keys).

-----Original Message-----
From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Samuel Hapák
Sent: Tuesday, July 21, 2015 08:29
To: es-discuss
Subject: Re: Extensible destructuring proposal

> On 21.7.2015, at 9:34, Andreas Rossberg <rossberg at google.com> wrote:
> People reading code will (rightfully) expect destructuring to be syntactic sugar for property access. I don't think it's worth breaking that equivalence. If you want user-defined patterns then they should be syntactically distinct from existing forms.

This is already not true for array destructuring. You can use it with any iterables, not only with arrays.

`@@get` should be implemented only by “Map like” data structures. Destructuring is usually used to extract deeply nested data from `Object`. I find hard to believe that someone would deliberately use destructuring on `Map` or similar structure to extract methods:

// very strange use of destructuring, don’t believe anyone is doing that const {get, has, set} = myMap // instance of Map() ```

Much more common use case is that you have nested structure of “Map like” structures and want to easily retrieve values.

Btw. this change is backward compatible, because it does not change behavior of existing code. It just gives you ability to provide users with new datastructures.

> Also, destructuring patterns are meant to match, and be the logical inverse of, literal syntax. Consequently, from my perspective at least, extensible destructuring would require first introducing extensible literal syntax in a symmetric manner. I think it would be unnecessarily surprising if for random patterns they didn't match up (worse, if you cannot even tell the meaning syntactically, but it depends on whatever object you happen to get).
As I have pointed out, this is not true for iterable destructuring.

[a, b, c] = someIterable; // someIterable does not have to be Array ```

This can be similarly surprising:
`someIterable[0] !== a // true`



More information about the es-discuss mailing list