GeezerVison

Is this the real life? 😍

TypeScript Bot (@typescript-bot) test this.

Heya Wenlu Wang (@Kingwl), I've started to run the extended test suite on this PR at 2327b3b. You can monitor the build here. It should now contribute to this PR's status checks.

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

declare let a: any, b: any, c: any;

let x1 = (a ?? b as any) || c;
let x2 = c || (a ?? b as any);
let x3 = ((a ?? b) as any) || c;
let x4 = c || ((a ?? b) as any);
let x5 = (a ?? b) as any || c;
let x6 = c || (a ?? b) as any;

let y1 = (a ?? b as any) && c;
let y2 = c && (a ?? b as any);
let y3 = ((a ?? b) as any) && c;
let y4 = c && ((a ?? b) as any);
let y5 = (a ?? b) as any && c;
let y6 = c && (a ?? b) as any;

Daniel Rosenwasser (@DanielRosenwasser) I've added the tests, emit appears to work as expected keeping the () around the a ?? 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 😅

Ron Buckton (@rbuckton) or Daniel Rosenwasser (@DanielRosenwasser)
One thing I noticed was that emit is using the actual identifier in the down level version of ??. So x ?? 0 becomes typeof x !== undefined && x !== null ? x : 0.

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

//test2.ts
let x = { y: 1, x: 0 }
let v = 0;
Object.defineProperty(x, "x", {
    get() {
        return v++;
    }
})
export = x;
//usage.ts
import { x, y } from './test2'
let xo = x ?? "NO"
console.log(xo);
let yo = y ?? "NO"
console.log(yo);

This will output 2 and 1 because let xo = x ?? "NO" becomes var 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 always ex. Thoughts ?

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

Daniel Rosenwasser (@DanielRosenwasser) Mkay 😕, so ignore the corner case above ?

Just to make sure I was clear in what I was trying to say x ?? "NO" is seen as using an identifier in the esnext transform, but the commonJS transformation will effectively turn it into test2_1.x ?? "NO" (with the actual result being typeof test2_1.x !== "undefined" && test2_1.x !== null ? test2_1.x : "NO"; )

Titian Cernicova-Dragomir (@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 (@typescript-bot) pack this.

Heya Wenlu Wang (@Kingwl), I've started to run the tarball bundle task on this PR at 57be95d. You can monitor the build here. It should now contribute to this PR's status checks.

Hey Wenlu Wang (@Kingwl), I've packed this into an installable tgz. You can install it for testing by referencing it in your package.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 running npm install.

I’ll update that today

Wenlu Wang (@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. For foo ?? bar, was document.all the reason for choosing foo !== null && foo !== void 0 as the conditional expression in the compiled output, as opposed to the abstract equality comparison foo != null? 😅

let x = (foo !== null && foo !== undefined) ? foo : bar;
// vs
let x = foo != null ? foo : bar;

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