Existential Operator / Null Propagation Operator

Kevin Smith zenparsing at gmail.com
Tue Apr 7 02:12:52 UTC 2015


We should perhaps review this old thread:

https://esdiscuss.org/topic/fail-fast-object-destructuring-don-t-add-more-slop-to-sloppy-mode

for another possible way to avoid non-compositionality.  (Look for the
suggestion about "Nil".  It's basically an exotic falsey object which
returns itself for any property lookups or calls.)


On Mon, Apr 6, 2015 at 10:05 PM, Dmitry Soshnikov <
dmitry.soshnikov at gmail.com> wrote:

> On Mon, Apr 6, 2015 at 6:35 PM, Dmitry Soshnikov <
> dmitry.soshnikov at gmail.com> wrote:
>
>> On Mon, Apr 6, 2015 at 11:33 AM, Christoph Pojer <
>> christoph.pojer at gmail.com> 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`?
>>>
>>> It appears that C# chose option #2 whereas Hack and CoffeeScript chose
>>> option #1. Our current implementation chose option #1
>>
>>
>> Hold on, I guess it's a typo, since as discussed in the internal
>> conversation, and based on the implementation, your current prototype
>> transform implements option (2). I.e. it's not yet compositional.
>> CoffeeScript also has option (2), and is not compositional, since:
>>
>> `a?.b.c` and `(a?.b).c` have different semantics in case if `a` is `null`.
>>
>>
>>> but we'd be
>>> happy to build a reference implementation for option #2.
>>>
>>>
>> Yeah, (2) will make it compositional.
>>
>>
>
> Err, option (1) I meant of course.
>
> Dmitry
>
> _______________________________________________
> 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/4afe37ce/attachment.html>


More information about the es-discuss mailing list