Existential Operator / Null Propagation Operator

Jordan Harband ljharb at gmail.com
Mon Apr 6 19:01:25 UTC 2015


Wouldn't option 1 provide the transitivity you're discussing? If `a?.b.c`
calls `(void 0).c` then `(a?.b).c` and `a?.b.c` would be identical, and
both throw a TypeError.

>From my reading, it seems like option 2 is the one that does not provide
transitivity, and tbh would surprise me greatly in the context of JS. If I
want the short circuit in option 1, I'd do `a?.b?.c` to indicate that,
whereas in option 2 if I don't want the short circuit, I'm forced to use
separate variables.

On Mon, Apr 6, 2015 at 11:40 AM, Herby Vojčík <herby at mailbox.sk> wrote:

>
>
> Christoph Pojer wrote:
>
>> Tim Yung and I have hacked on a reference implementation for the
>> "Existential Operator" using esprima-fb and jstransform: "a?.b"
>>
>> Example:
>>
>> `a?.b` =>  `(a == null ? void 0 : a.b)`
>> `a?.b.c` =>  `(a == null ? void 0 : a.b.c)`
>>
>> This must also make sure that `a` only gets evaluated a single time.
>>
>> Based on previous discussions on es-discuss and TC39, it seems that
>> this was tabled for ES6. I think now is a good time to bring it up for
>> ES7. There is precendence for this feature in other languages - it was
>> recently added to C# and Hack and has always been in CoffeeScript.
>> TypeScript is waiting for TC39:
>> https://github.com/Microsoft/TypeScript/issues/16
>>
>> In the past, this topic has invited a lot of bikeshedding, but I'd
>> like us to look past this. Several communities within and outside the
>> JS community have identified the need for this operator. My
>> understanding is that a decision needs to be made about whether the
>> operator should short-circuit additional invocations in the call chain
>> if the operand is null (aka. null propagation).
>>
>> For example, if `a` is null, should `a?.b.c`:
>>
>> 1) evaluate to `(void 0).c` and throw a TypeError?
>> 2) short-circuit at `a` and return `void 0`?
>>
>
> I liked the result of using a Null Pattern inside and materializing it
> outside, which once seemed to be plausible, with that `a?.b.c` would be
> `void 0` of course. I don't remember on what it all died back then (yes, I
> have a bias, I wanted a true null pattern, AWB than said it is good inside
> but not really good as first class person).
>
>  It appears that C# chose option #2 whereas Hack and CoffeeScript chose
>> option #1. Our current implementation chose option #1 but we'd be
>> happy to build a reference implementation for option #2.
>>
>> I recall that another issue was that of transitivity. Right now,
>> (a.b).c and a.b.c are equivalent. (a?.b).c and a?.b.c would not be
>> equivalent expressions. I think we need some input from the people on
>> this list about whether this is okay or why we value transitivity for
>> this operator.
>>
>> If we can come to an agreement on the existential operator for member
>> expressions, we would also be setting a precedent for other features
>> of the same family. For example, existential call expressions: `fn?()`
>> which would conditionally invoke `fn`.
>>
>> esprima-fb change: https://github.com/cpojer/esprima/tree/existential-
>> operator
>> jstransform change:
>> https://github.com/yungsters/jstransform/tree/existential-operator
>>
>> Previous discussions on es-discuss:
>> * https://esdiscuss.org/topic/the-existential-operator
>> * https://esdiscuss.org/topic/specifying-the-existential-
>> operator-using-abrupt-completion
>> * https://esdiscuss.org/topic/sept-18-tc39-meeting-notes
>>
>>  _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150406/04a1265a/attachment-0001.html>


More information about the es-discuss mailing list