fail-fast object destructuring (don't add more slop to sloppy mode)

Brendan Eich brendan at
Wed Jan 2 12:20:17 PST 2013

Herby Vojčík wrote:
> Brendan Eich wrote:
>> Kevin Smith wrote:
>>> Interpreted this way, any additional irrefutable markers in a
>>> subtree under a refutable identifier become redundant, correct?
>>> Er, meant this:
>>> Interpreted this way, any additional irrefutable markers in a subtree
>>> under an _irrefutable_ identifier become redundant, correct?
>> For the proposal to use Nil for the expression semantics, yes.
>> You're right, this implies destructuring binding forms behave in a way
>> that I flagged as possibly not wanted:
>> let {p?: {q: r}} = o;
>> would bind r to undefined for any o that doesn't have a p or that does
> In my view it binds to Nil (but it is falsey, == null etc., typeof 
> 'undefined' so it should work).

I don't think we should multiply risk by coupling destructuring (which 
is in ES6) to Nil (an unproposed strawman) at this point.

In theory and ignoring schedule and order of work, we could, and doing 
so has some symmetry (or really some duality) with a Nil-under-the-hood 
for ?. as existential operator. This is not a strong motivation in my view.

Also, would you really produce nil not undefined only for patterns where 
? was used and the pattern irrefutably succeeded because of a missing 
property, and otherwise (no ?-pattern involved) bind r to undefined? IOW

   let {p: {q?: r}} = {p: {s: 42}};

binds r to nil, while

   let r = {p: {s: 42}}.r;

of course binds r to undefined? That seems undesirable.

*If* we agree to put nil in the language (ideally as a stdlib component, 
self-hosted or self-hostable), then we need to be careful about where it 
is observable. Just because one could use it under the hood to implement 
?. does not mean it should be the result of ?-pattern default-matching.


More information about the es-discuss mailing list