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