fail-fast object destructuring (don't add more slop to sloppy mode)
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
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
More information about the es-discuss