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

Brendan Eich brendan at mozilla.com
Wed Jan 2 13:06:41 PST 2013


Herby Vojčík wrote:
> 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?

Er, yes! Sorry about that.

> This binds r to nil as well.

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.

>
>> 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".

s/composable/compositional/

That was about CoffeeScript's semantics based on transcompilation, which 
I showed a few messages back. From Andreas's comments as captured in the 
minutes:

"""

ARB: This is non-compositional

         o = {}
         r = o?.p.q.r
         r = (o?.p).q.r
         r = o?.p.q.r()

Results in…

         var o, r;
         o = {};
         r = o != null ? o.p.q.r : void 0;
         r = (o != null ? o.p : void 0).q.r;
         r = o != null ? o.p.q.r() : void 0;

Non-starter.

"""


> With internal-nil-exposed-undefined, these are different:
>
>     (p.q?).r
>     p.q?.r
>
> With nil-reified, those are identical.

Yes, I already agreed (three times :-|) that nil rescues ?. from the 
condemnation ARB heaped on the CoffeeScript semantics.

That's not relevant to what we were just arguing about though: whether 
nil rather than undefined should be an observable result of either 
destructuring or (you seemed to say just above) property gets on plain 
old objects!

/be


More information about the es-discuss mailing list