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.soshni...@gmail.com> wrote: > On Mon, Apr 6, 2015 at 6:35 PM, Dmitry Soshnikov < > dmitry.soshni...@gmail.com> wrote: > >> On Mon, Apr 6, 2015 at 11:33 AM, Christoph Pojer < >> christoph.po...@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@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
