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

Brendan Eich brendan at
Wed Jan 2 13:06:41 PST 2013

Herby Vojčík wrote:
> Brendan Eich wrote:
>> 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;
> You meant let r = {p: {s: 42}}.p.q?, didn't you?

Er, yes! Sorry about that.

> This binds r to nil as well.

Confusion. Let me write it out to be sure we are talking about the same 

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

binds nil to r? That's not backward compatible.

>> of course binds r to undefined? That seems undesirable.
> Yes. But one of the problems mentioned on this thread was ARB's "It's 
> not composable".


That was about CoffeeScript's semantics based on transcompilation, which 
I showed a few messages back. From Andreas's comments as captured in the 


ARB: This is non-compositional

         o = {}
         r = o?.p.q.r
         r = (o?.p).q.r
         r = o?.p.q.r()

Results in…

         var o, r;
         o = {};
         r = o != null ? o.p.q.r : void 0;
         r = (o != null ? o.p : void 0).q.r;
         r = o != null ? o.p.q.r() : void 0;



> With internal-nil-exposed-undefined, these are different:
>     (p.q?).r
>     p.q?.r
> With nil-reified, those are identical.

Yes, I already agreed (three times :-|) that nil rescues ?. from the 
condemnation ARB heaped on the CoffeeScript semantics.

That's not relevant to what we were just arguing about though: whether 
nil rather than undefined should be an observable result of either 
destructuring or (you seemed to say just above) property gets on plain 
old objects!


More information about the es-discuss mailing list