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

Herby Vojčík herby at mailbox.sk
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 
enough.

In the light of this I think nil-underneath-resurfaced-as-undefined is 
good strategy, things like
   (foo=o.p?).q
must be augmentede a bit more:
   (foo=o.p?)?.q

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

> /be

Herby


More information about the es-discuss mailing list