destructuring: as patterns?

Andreas Rossberg rossberg at google.com
Sat Apr 21 02:07:51 PDT 2012


On 21 April 2012 01:08, Brendan Eich <brendan at mozilla.org> 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?

/Andreas


More information about the es-discuss mailing list