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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
