Brendan Eich wrote:
Herby Vojčík wrote:
Brendan Eich wrote:
Kevin Smith wrote:

Interpreted this way, any additional irrefutable markers in a
subtree under a refutable identifier become redundant, correct?


Er, meant this:

Interpreted this way, any additional irrefutable markers in a subtree
under an _irrefutable_ identifier become redundant, correct?

For the proposal to use Nil for the expression semantics, yes.

You're right, this implies destructuring binding forms behave in a way
that I flagged as possibly not wanted:

let {p?: {q: r}} = o;

would bind r to undefined for any o that doesn't have a p or that does

In my view it binds to Nil (but it is falsey, == null etc., typeof
'undefined' so it should work).

I don't think we should multiply risk by coupling destructuring (which
is in ES6) to Nil (an unproposed strawman) at this point.

In theory and ignoring schedule and order of work, we could, and doing
so has some symmetry (or really some duality) with a Nil-under-the-hood
for ?. as existential operator. This is not a strong motivation in my view.

Also, would you really produce nil not undefined only for patterns where
? was used and the pattern irrefutably succeeded because of a missing
property, and otherwise (no ?-pattern involved) bind r to undefined? IOW

let {p: {q?: r}} = {p: {s: 42}};

binds r to nil, while

let r = {p: {s: 42}}.r;

You meant let r = {p: {s: 42}}.p.q?, didn't you?
This binds r to nil as well.

of course binds r to undefined? That seems undesirable.

Yes. But one of the problems mentioned on this thread was ARB's "It's not composable".

With internal-nil-exposed-undefined, these are different:

        (p.q?).r
        p.q?.r

With nil-reified, those are identical.

*If* we agree to put nil in the language (ideally as a stdlib component,
self-hosted or self-hostable), then we need to be careful about where it
is observable. Just because one could use it under the hood to implement
?. does not mean it should be the result of ?-pattern default-matching.

/be

Herby
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to