Is this the real life? 😍

@typescript-bot test this.

Heya@Kingwl, I've started to run the extended test suite on this PR at2327b3b. You can monitor the buildhere. It should now contribute to this PR's status checks.

.js emit test cases I'd like you to consider when targeting ESNext:

declareleta:any,b:any,c:any;letx1=(a??basany)||c;letx2=c||(a??basany);letx3=((a??b)asany)||c;letx4=c||((a??b)asany);letx5=(a??b)asany||c;letx6=c||(a??b)asany;lety1=(a??basany)&&c;lety2=c&&(a??basany);lety3=((a??b)asany)&&c;lety4=c&&((a??b)asany);lety5=(a??b)asany&&c;lety6=c&&(a??b)asany;

@DanielRosenwasser I've added the tests, emit appears to work as expected keeping the() around thea ?? b. So as to conform to the grammar requirement that:

?? cannot immediately contain, or be contained within, an&& or|| operation.

Hope I didn't miss the point of the tests 😅

@rbuckton or@DanielRosenwasser
One thing I noticed was that emit is using the actual identifier in the down level version of??. Sox ?? 0 becomestypeof x !== undefined && x !== null ? x : 0.

But ifx comes from an import, because of the order in which the transformations are applied, we might get side effects on the access tox:

//test2.tsletx={y:1,x:0}letv=0;Object.defineProperty(x,"x",{get(){returnv++;}})export=x;//usage.tsimport{x,y}from'./test2'letxo=x??"NO"console.log(xo);letyo=y??"NO"console.log(yo);

This will output2 and1 becauselet xo = x ?? "NO" becomesvar xo = typeof test2_1.x !== "undefined" && test2_1.x !== null ? test2_1.x : "NO"; which will call the getter multiple times.

I would just use the approach babel uses, use a temporary variable alwaysex. Thoughts ?

I think "use a temporary unless it's an identifier" is usually the approach we take.

@DanielRosenwasser Mkay 😕, so ignore the corner case above ?

Just to make sure I was clear in what I was trying to sayx ?? "NO" is seen as using an identifier in theesnext transform, but thecommonJS transformation will effectively turn it intotest2_1.x ?? "NO" (with the actual result beingtypeof test2_1.x !== "undefined" && test2_1.x !== null ? test2_1.x : "NO";)

@dragomirtitian
I prefer it to be a side effect (or feature) of cjs.
not only this one but also many other syntaxes.

But i felt assign to temp variable is better

@typescript-bot pack this.

Heya@Kingwl, I've started to run the tarball bundle task on this PR at57be95d. You can monitor the buildhere. It should now contribute to this PR's status checks.

Hey@Kingwl, I've packed this intoan installable tgz. You can install it for testing by referencing it in yourpackage.json like so:

{    "devDependencies": {        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/44785/artifacts?artifactName=tgz&fileId=64FF4F06CBE74357042C0E22BEF9D252966E889A57B59FEB9CE7822F7DA3784002&fileName=/typescript-3.7.0-insiders.20190920.tgz"    }}

and then runningnpm install.

I’ll update that today

@Kingwl: Thanks for the contribution!

My changes were mostly to merge the control-flow behavior of nullish-coalesce with the control-flow behavior of optional chaining and to resolve merge conflicts so that this could be merged with master for the 3.7 beta. Thanks again for all of the hard work!

Thank you all for your hard work on this and congrats on the 3.7 release!

I have a small question out of curiosity. Forfoo ?? bar, wasdocument.all the reason for choosingfoo !== null && foo !== void 0 as the conditional expression in the compiled output, as opposed to theabstract equality comparisonfoo != null? 😅

letx=(foo!==null&&foo!==undefined) ?foo :bar;// vsletx=foo!=null ?foo :bar;

was document.all the reason for
@wsmd
#32883 (comment)
#32883 (comment)