destructuring: as patterns?

Brendan Eich brendan at
Fri Apr 20 14:22:47 PDT 2012

Andreas Rossberg wrote:
> Honestly, my
> feeling is that strictly sticking to that principle will overly
> constrain pattern syntax anyway, if not for 'as' then for the next
> nice feature. I dimly remember that we had it coming up before.

Dave and I were talking about making fail-soft or "irrefutable match" 

js> let {x} = {};
js> x

(SpiderMonkey shell.)

IOW, destructuring has been conceived of as pretty thin sugar for 
getting a property, and if no such property, you get undefined. Of 
course, this makes a deeper pattern fail hard:

js> let {y:{z}} = {};
typein:4: TypeError: (void 0) is undefined

(Atrocious SpiderMonkey failure to pretty-print the blamed expression 
instead of its portable (void 0) value there -- my fault I think.)

Dave suggested making the first case, let {x} = {}, throw, and requiring 
? as a pattern modifier (I suggested prefix):

let {?x} = {}; // x is undefined, no throw
let {y} = {};  // throws

So there's another place the pattern language wants to diverge from 
object literal notation.

> One alternative of course would be to restrict what can occur in an
> assignment pattern, compared to bindings. The two are quite different
> semantically, so it could perhaps be argued. But it's not the most
> pleasant idea either.

Turns out Allen has already done this in ES6 drafts. 11.13.1 is for 
destructuring assignment. 12.2.4 is destructuring binding patterns. So 
we can diverge patterns further.


More information about the es-discuss mailing list