TypeScript Bot (@typescript-bot) test this
TypeScript Bot (@typescript-bot) user test this
TypeScript Bot (@typescript-bot) run dt
TypeScript Bot (@typescript-bot) perf test this

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the parallelized community code test suite on this PR at 0bed057. You can monitor the build here.

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the perf test suite on this PR at 0bed057. You can monitor the build here.

Update: The results are in!

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the parallelized Definitely Typed test suite on this PR at 0bed057. You can monitor the build here.

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the extended test suite on this PR at 0bed057. You can monitor the build here.

Cooooooooooooooool!!!!!! Great work!!!!!

Anders Hejlsberg (@ahejlsberg)
The results of the perf run you requested are in!

Comparison Report - main..44730

Download Benchmark

is there a reason for specifically limiting the nesting analysis to two levels?

I'd like to have a fixed limit so we can avoid maintaining a stack of inlined symbols that would otherwise be needed (to catch accidentally recursive definitions). Two levels is rather arbitrary, could make it three or even five.

I think the new tests have been elided

Yeah, haven't added tests yet.

TypeScript Bot (@typescript-bot) pack this

Heya Ryan Cavanaugh (@RyanCavanaugh), I've started to run the tarball bundle task on this PR at 0bed057. You can monitor the build here.

I'm interested in some with readonly props, both static and instance, since those don't have examples in your OP, but are referenced in some comments, even though later there's a check for exactly VariableDeclarations

The isVariableDeclaration checks are all related to the declaration of the aliased condition or discriminant access, and are unrelated to how the referenced being narrowed was declared. But sure, we should have tests for all different kinds.

Hey Ryan Cavanaugh (@RyanCavanaugh), 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/105495/artifacts?artifactName=tgz&fileId=94FC84B182999B7D6DCA47117848030F812A9A364841F767F760CB8D5DBAAF0402&fileName=/typescript-4.4.0-insiders.20210624.tgz"
    }
}

and then running npm install.

There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/pr-build@4.4.0-pr-44730-11".;

Is it possible to also add narrowing for constants from same destructurization?

function test(data: { type: "num", value: number } | { type: "str", value: string }) {
  const { type, value } = data;
  if (type === "num") {
    value.toFixed(); // currently error
    data.value.toFixed(); // ok
  } else {
    value.charAt(0); // currently error
    data.value.charAt(0); // ok
  }
}

UPD. As mentioned in edit I've missed - maybe later, but not in this PR.

Anders Hejlsberg (@ahejlsberg), would that be possible to extend this for classes as well, e.g.:

class T {
    s = "";
}

function f1(x: unknown) {
    const isT = x instanceof T;
    if (isT) {
        x.s;  // Ok
    }
}

Also, maybe to include some other type checks, e.g., const isString = x?.constructor === String, which works for both primitive string values and instances of String class.

Anders Hejlsberg (@ahejlsberg), would that be possible to extend this for classes as well, e.g.:

class T {
    s = "";
}

function f1(x: unknown) {
    const isT = x instanceof T;
    if (isT) {
        x.s;  // Ok
    }
}

Already working https://www.staging-typescript.org/play?ts=4.4.0-pr-44730-11#code/MYGwhgzhAEAq0G8BQ1XRgXmgImwbiQF8kkAzAVwDtgAXASwHtLpSBGACgA8AuaKga0oMA7pQCUiFGmBMINaHQjwsnBZTlhqAUwak4BNAr3tFsCckOHOAOgh5UAegfQA8vympihIA ❤️

Already working

Very cool! Interestingly, I can use object instead of unknown and it still works :)

Narrowing through indirect references occurs only when the conditional expression or discriminant property access is declared in a const variable declaration with no type annotation, and the reference being narrowed is a const variable, a readonly property, or a parameter for which there are no assignments in the function body.

Should I take this mean narrowing won't work on non-readonly properties? That limits the utility of this IMO; I pretty much never use the readonly keyword in my interfaces.

Should I take this mean narrowing won't work on non-readonly properties? That limits the utility of this IMO; I pretty much never use the readonly keyword in my interfaces.

Correct. For example, the following fails if data isn't marked readonly:

function test(obj: { readonly data: string | number }) {
    const isString = typeof obj.data === 'string';
    if (isString) {
        let s: string = obj.data;
    }
}

The rationale here is that we can't know for certain that data hasn't been modified since the condition was evaluated. We'd effectively have to check that there are no assignments to obj.data between the declaration of isString and the reference to isString in the if statement. This adds complexity and could be prohibitively expensive.

It does of course work if you copy the mutable property into a const local:

function test(obj: { data: string | number }) {
    const { data } = obj;
    const isString = typeof data === 'string';
    if (isString) {
        let s: string = data;
    }
}

Cross-linking to #30581.

Thanks Joe Calzaretta (@jcalz) ! Correlated unions sound cool!

Anders Hejlsberg (@ahejlsberg) would this be the correct issue to watch for this feature of "coupling" between destructured properties / elements?

Anders Hejlsberg (@ahejlsberg)
Could it maybe possible to reflect on the type that is hold that predicate behaviour ?

That would be to prevent that kind of weird behaviour !