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

Herby Vojčík herby at
Tue Jan 8 07:22:25 PST 2013

Brendan Eich wrote:
> Herby Vojčík wrote:
>>>>> We need to detail how Nil works, how it cannot be wrapped or observed,
>>>>> etc. in order to maintain equivalence.
>>>> In my naive view, [[GetP]] returns Nil, [[SetP]] does nothing,
>>>> [[Call]] return Nil. But there are sure some nasty details down there.
>>> Yeah, this is unsafe by design, if the spec has a bug then Nil leaks
>>> out. Want undefined in ES6, not Nil.
>> I don't understand the unsafety. If Nil is observable part of the
>> language, then this is natural semantics. If it should be hidden,
>> that's another story.
> I assumed from context (cited above) that you were talking about
> destructruing in ES6. That spec lacks Nil as an observable and must
> censor any internal Nil specification type. Could be done, but I argue
> it's safer to leave [[GetP]] etc. dealing in undefined for now.
> Of course if we want Nil in the language, then full speed ahead! That
> would be later (ES7 or above), if ever.

Well, the objection that reified nil hides errors is valid; it bugged 
me, too. I pondered how it can be solved, or if it will be obstacle big 

In the light of this I think nil-underneath-resurfaced-as-undefined is 
good strategy, things like
must be augmentede a bit more:

I think it is a problem only for existential operator, destructuring has 
no subexpressions.

> /be


More information about the es-discuss mailing list