destructuring: as patterns?

David Herman dherman at
Wed Apr 18 14:35:46 PDT 2012

Agreed. This is easy to spec and implement, highly composable (it fits neatly into the algebra of destructuring patterns everywhere, as opposed to just in object property-name positions), has no problems with side effects, and does not violate restrictions that IINM strict mode is supposed to ban (repeated property names in literals).

The repeated property-name thing is a hack. It does not Say What You Mean (it's a total surprise). It is not composable (it only works for property names, not for array indices).

Worst of all, it will trigger getters twice:

    > let { b, b: { x, y } } = { get b() { console.log("BOO!"); return 17 } }

But if that's the only way to do it, then if you want to destructure a getter, you will be forced not to use the hack, and to bind a temporary variable and do a second destructuring on a second line.

*Please*, let's do this right. There's no reason to introduce hacks. I'm open to various syntaxes, but I think `as` is nice especially because it could work well for import/export syntax too. Lots of people complain about confusion over which is the bound name and which is the label. IINM, we could allow both:

    let { x: x as y } = obj;


    let { x as y } = obj;

which would be a nice idiom for making it more obvious that x is the label and y is the binding. Then this would be especially nice for imports:

    import { x as y } from X;


On Apr 18, 2012, at 8:57 AM, Andreas Rossberg wrote:

> On 18 April 2012 17:51, Herby Vojčík <herby at> wrote:
>> Maybe allowing
>>  let {b, b:{x,y}} = obj;
>> would be enough. It sort-of comforms to existing syntax as well as
>> semantics.
> That won't work for arrays, for example.
> I agree that 'as' patterns (and even more so, wildcard patterns) are
> basic building blocks that are currently missing. They are extremely
> useful in practice, for a very small price -- i.e., they are trivial
> to spec and implement, (unlike callable objects, because Brendan just
> mentioned those :) ).
> /Andreas
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list