destructuring: as patterns?

Brendan Eich brendan at mozilla.org
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" 
opt-in:

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.

/be


More information about the es-discuss mailing list