destructuring: as patterns?

Brendan Eich brendan at
Sat Apr 21 08:41:56 PDT 2012

Andreas Rossberg wrote:
> Clearly, it's not
> possible to correct that, but why should that imply that all new
> features need to inherit sloppy semantics, too?

There's no strict logical implication. On the plus side, the new 
features are stricter (if you are pro-strict and anti-"sloppy" -- let's 
assume we all agree on this, pace Herby).

On the minus side, you're making the language a mixture of strictness 
that is more complicated (who cares about "legacy"?) and possibly harder 
to use in practice. The "in practice" part is crucial.

We've all had bugs in JS code where you pull out undefined (due to a 
property name typo, e.g. -- more insidiously due to type confusion) and 
it flows way downstream before someone notices. This is a pain. But it's 
in the language. Does trying to close the barn door only for 
destructuring -- closing the new upper half of the dutch-style door -- 
help? The lower half is wide open.

Users who want the strictness can use destructuring always:

   let {p} = o;

instead of

   let p = o.p;

and get an error on missing o.p -- that could be the new style for those 
wanting to avoid the legacy behavior. If that's the idea, I get it. But 
I'm skeptical that such an intentional style will be adopted widely, or 
at all. There's no help for all the open-coded

   if (o.p) ...

etc. uses that evaluate to undefined when p is not in o.


More information about the es-discuss mailing list