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

Brendan Eich brendan at
Wed Jan 2 13:36:33 PST 2013

[Trimming overcited top text.]

Herby Vojčík wrote:
>> Confusion. Let me write it out to be sure we are talking about the same
>> thing:
>> let r = {p: {s: 42}}.p.q;
>> binds nil to r? That's not backward compatible.
> Sorry, I did wrote it so it could lead to confusion.
> Let me try to explain better.
>     (1)    let {p: {q?: r}} = {p: {s: 42}};
>         // me: r = Nil, you: ???, probably undefined

Yes. For the reason I gave: destructuring in ES6 cannot depend on Nil, 
but I argue should include irrefutable opt-in via suffix-?.

>     (2)    let r = {p: {s: 42}}.p.q?;
>         // me: r = Nil, you: ???, probably undefined

Yes, undefined. For the reason I gave, not coupling too much among ES7 
or later straw proposals.

>     (3)    let {p: {q: r}} = {p: {s: 42}};
>         // r = undefined (of course)

No issue, great.

>     (4)    let r = {p: {s: 42}}.p.q;
>         // r = undefined (of course)

No issue, great. Whew!

> You compared (1) to (4). I would it is comparing apples to oranges, 
> and that (1) and (2) or (3) and (4) should be compared.

Apologies, on re-reading I see I misread your trailing '?' after 'q' in

>  You meant let r = {p: {s: 42}}.p.q?, didn't you?

>> That's not relevant to what we were just arguing about though: whether
>> nil rather than undefined should be an observable result of either
> Now I am confused.
> For (p.q?).r to be same as p.q?.r, (p.q?) must return reified Nil, not 
> undefined. I was at the impression you say "Nil at the background, but 
> whenever it becomes observable, it should be changed to undefined". 
> That means p.q? returns undefined, and (p.q?).r fails.

Obviously I don't want these different parenthesizations to fail. I 
believe we can spec the semantics such that InternalNil, just like 
ES1-6's Reference type, is not observable.


More information about the es-discuss mailing list