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

Herby Vojčík herby at
Wed Jan 2 12:55:44 PST 2013

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:


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


More information about the es-discuss mailing list