GeezerVison

I've been looking forward to Optional Chaining in TypeScript for a long time! Looking forward to seeing this PR land. :)

I'm curious, what was the reason that you decided to emit (_a = a) === null || _a === void 0 instead of the shorter (_a = a) == null?

var _a, _b, _c;
(_a = a) == null ? void 0 : _a.b; // optional property access 'a?.b'
(_b = a) == null ? void 0 : _b[x]; // optional element access 'a?.[x]'
(_c = a) == null ? void 0 : _c(); // optional call 'a?.()'

This is super exciting 🎉 Any plans to surface a type error if the value is not either null or undefined? In which case it's unnecessary, so having that be an error would be sorta like TS2367, and we can avoid the runtime overhead

Marius Schulz (@mariusschulz) See #16 (comment)

Simen Bekkhus (@SimenB) surfacing an error there would only help perfectly typed projects avoid runtime slowdowns, but it would also impose a syntax tax on projects that have to deal with the real world — infinite node_modules that are only partially typed, or where the types aren’t accurate. I wouldn’t want to have to cast (improperlyTyped as any)?.foo?.bar As this kind of would defeat some of the value of this operator.

I’d support a flag defaulting to off, --strictOptionalChaining, however!

Any plans to surface a type error if the value is not either null or undefined?

Not at this time, no. Such an error would only be valid under strict mode (since ?. has no effect on types in non-strict mode), and would prevent you from writing defensive code against external APIs that are possibly unsafe. Also, we do not currently do this for the non-null assertion operator (!), so it would not make sense for us to do that here as well.

That kind of rule may be better implemented as a lint rule rather than a TypeScript-specific flag.

Actually,

a?.b // optional property access
a?.[x] // optional element access
a?.() // optional call

should get transpiled to:

var _a, _a2, _a3;

(_a = a) === null || _a === void 0 ? void 0 : _a.b; // optional property access
(_a2 = a) === null || _a2 === void 0 ? void 0 : _a2[x]; // optional element access
(_a3 = a) === null || _a3 === void 0 ? void 0 : _a3(); // optional call

ExE Boss (@ExE-Boss): How does your example differ from my example in the description?

Yours uses:

var _a, _b, _c; // Implies optional access from different variables `a`, `b` and `c`.

Whereas mine uses

var _a, _a2, _a3; // Implies distinct optional accesses from variable `a`.

There is, in fact, a lint rule for that, though it will need to be updated for the ?. case. tslint / eslint

TypeScript Bot (@typescript-bot) pack this

Heya Orta Therox (@orta), I've started to run the tarball bundle task on this PR at c2f53fc. You can monitor the build here. It should now contribute to this PR's status checks.

Hey Orta Therox (@orta), 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/45184/artifacts?artifactName=tgz&fileId=4C24B3EBE47F04661C6F0C3769DECEBF2B693C39E432217A9786260BDF23992502&fileName=/typescript-3.7.0-insiders.20190923.tgz"
    }
}

and then running npm install.

Here's a playground

To use the new PR in playground feature 😊, it seems intelisense has no suggestions ?. for primitive type:

declare let x: string | undefined;
let l = x?.length // no intelisense for length

Play

Are we planning on including completions that convert . to ?. later, or is there a reason not to? I pulled down this PR and did a quick prototype:

TypeScript Bot (@typescript-bot) perf test this

Heya Ron Buckton (@rbuckton), I've started to run the perf test suite on this PR at 0828674. You can monitor the build here. It should now contribute to this PR's status checks.

Update: The results are in!

Ron Buckton (@rbuckton)
The results of the perf run you requested are in!

❤️

Hello, I'm not sure were to leave it, but there are some syntax problems in target code:

https://www.typescriptlang.org/play/?ts=3.7.0-pr-33294-11#code/MYewdgzgLgBAZiEMC8MAUYBcMwFcC2ARgKYBOAlCgHw4DcAsAFCiSyECGpK6YA-NniJlKyGghAZeAOnK0gA

ekfn the TS version there is from an earlier commit in this PR. That issue was fixed—you can see it give a proper error in the nightly: https://www.typescriptlang.org/play/?ts=Nightly#code/MYewdgzgLgBAZiEMC8MAUYBcMwFcC2ARgKYBOAlCgHw4DcAsAFCiSyECGpK6YA-NniJlKyGghAZeAOnK0gA

Wait sorry, it looks like the playground doesn’t have the new nightly yet. Here’s the commit where it was fixed, at any rate: e073c05

And here’s a screenshot of it working in master:

Andrew Branch (@andrewbranch) now it works on playground too.

For me, the playground does show a syntax error, but it’s because it starts to parse as a conditional expression:

Subtle difference, but you can tell because the JavaScript emit in the right pane emits a conditional expression with empty true and false sides, and none of the var _a helper variables associated with optional expressions 😄

Sorry, my comment was that nightly works.

I understand that the last nightly have this PR and #32883 included (or maybe it loads the previous nightly). Something its wrong because it try to parse ?. and ?? as ?: (the last one as a two ?: operators).

Edit: locally with 3.7.0-dev.20191001 I see the same errors as on playground.

3.7.0-dev.20191001, shown here, definitely works, but for me loading Nightly on the playground is clearly loading an older build. I’m not sure how to tell for sure what build it is. /cc Orta Therox (@orta)?

Tested again locally and it works both (this PR and #32883). Probably I was using another version.

I've been looking forward to Optional Chaining in TypeScript for a long time! Looking forward to seeing this PR land. :)

I'm curious, what was the reason that you decided to emit (_a = a) === null || _a === void 0 instead of the shorter (_a = a) == null?

var _a, _b, _c;
(_a = a) == null ? void 0 : _a.b; // optional property access 'a?.b'
(_b = a) == null ? void 0 : _b[x]; // optional element access 'a?.[x]'
(_c = a) == null ? void 0 : _c(); // optional call 'a?.()'

Such as document.all in browser, peculiar results below:

document.all === void 0; // false
document.all === null; // false

// but
document.all == null; // true

If you are using @babel/plugin-proposal-optional-chaining, you can get as (_a = a) == null with option {loose: true }.

Optional chaining has now reached state 4: https://twitter.com/drosenwasser/status/1202310742436761600. Note, the README hasn't been updated yet.