destructuring: as patterns?

Herby Vojčík herby at
Sat Apr 21 02:56:24 PDT 2012

Andreas Rossberg wrote:
> On 21 April 2012 01:08, Brendan Eich<brendan at>  wrote:
>> Allen Wirfs-Brock wrote:
>>> What I'm really pushing at here is the throw. Let's are  used for
>>> establishing and initializing bindings.  From a binding perspective:
>>>     let x ;
>>> and
>>>     let {x} = {};
>>> are almost exactly the same thing.  They both establish a hoisted
>>> uninitialized lexical binding for x.  They both delimit the end of the TDZ
>>> for x. They both supply undefined as the initialization value of x. Why
>>> should the second form throw when the first doesn't?
>> That is a good question.
> It's about expression of intent. When you write
>    let x;
> it is syntactic sugar for
>    let x = undefined;
> So clearly, you want x to be undefined, and you pretty much said so
> explicitly. However, nobody ever writes
>    let {x} = {};
> What destructuring is meant for, and what programmers write in reality is
>    let {x, y} = someExpressionThatIsNotALiteral
> and here, the apparent intention is that someExpression results in an
> object with an x and y property. If it doesn't, that typically means
> there is a bug. And masking a bug and/or letting it proliferate
> silently is rarely a good idea. Much less so if the language does it
> implicitly.
> Now, a stricter semantics does not preclude that the language provides
> some convenient way to also express the sloppy intent for the cases
> where you really want it, which is what Brendan's ?-operator would do.
> So I'd be happy with that, as long as it is sufficiently explicit and
> not the default.
> Of course, it is absolutely true that the same argument can be made
> about someExpression.x, but I file that under historic legacy. If we
> were to design JS from scratch -- and with the ES6 feature set! --
> then I'd surely vote for making that throw as well (like, btw, I would
> for argument arity mismatches in function calls, if the callee doesn't
> have appropriate default or rest parameters). Clearly, it's not
> possible to correct that, but why should that imply that all new
> features need to inherit sloppy semantics, too?

I disagree. Borrowing from Alan Kay IIRC, this is like making an octopus 
from a dog by nailing more legs on it - that is, these two points of 
view are incompatible.

JS model _is_ about "sloppy semantics" (I do not call it sloopy, I'd 
rather called it liberal), that is, undefined if not present. It should 
not be changed in other part of languages as well, or it will be mess of 
learning where this applies and where opposite of this applies.

> /Andreas


More information about the es-discuss mailing list