The TypeScript team hasn't accepted the linked issue #16069. If you can get it accepted, this PR will have a better chance of being reviewed.

@typescript-bot perf test this faster

Heya @RyanCavanaugh, I've started to run the faster perf test suite on this PR at e2684f1. You can monitor the build here.

Update: The results are in!

I'm thinking this will break things like...

let isNumberable = (x: string | number) => typeof x === 'number';
isNumberable = x => !isNaN(parseInt(String(x)));

...as a function returning boolean is not assignable to a type predicate. This example is pretty contrived, but might be relevant for class inheritance (i.e. legal subclasses become illegal because the base class method now gets inferred as a typeguard).

@RyanCavanaugh
The results of the perf run you requested are in!

@fatcerberus true, but that can also cut the other way! See the deleted errors file for javascriptThisAssignmentInStaticBlock.ts.

Ryan pointed out on another issue that inferring a type guard breaks this sort of code as well #38390 (comment)

const a = [1, "foo", 2, "bar"].filter(x => typeof x === "string");
a.push(10);  // ok now, error with my PR

I assume the +3.89% check time on compiler-unions is bad? Is there any information on how I can run this locally and see what's going on?

The CI/self-check found a flaw in my criteria for inferring a type predicate. I actually need to be even more strict! I should not infer a type predicate for this function, even though Exclude<unknown, string> = unknown.

function isShortString(x: unknown) {
  return typeof x === 'string' && x.length < 10;
}

declare let str: string;
if (isShortString(str)) {
  str;  // string
} else {
  str;  // never
}

This is actually quite interesting. My approach has no way of distinguishing isShortString from:

function isString(x: unknown) {
  return typeof x === 'string';
}

They both have initType=unknown, trueType=string and falseType=unknown. It would be valid to infer a type guard for isShortString if it were only ever called with unknown types. But if you call it with something like string or string | number then you can see that one is a valid type guard while the other is not.

I need to think a little more about whether this is fixable or if it's a flaw with this whole approach.

Ouch, that's tricky. If there's a && present in the condition then you have to make sure there are no additional non-narrowing checks (or that the additional checks didn't narrow something else instead)

@fatcerberus yeah, see updated comment. I need to think about it a little more, but this might be a deal-breaker for this approach.

Negated types would be a great help here because the falseType would then be unknown & !string and the Exclude-based test would be sufficient.

nevermind, I'm dumb, you haven't ruled out all strings. ignore this

I'm feeling somewhat hopeful that this approach can be salvaged. Instead of requiring that:

falseType = Exclude<initType, trueType>

what we actually need is:

falseType = Exclude<T, trueType> \forall T <: initType

i.e. that this relationship holds for all subtypes of the declared type. I'm hoping that in practice this just means I need to check that the relationship holds for T=initType and T=trueType, i.e. add one more check.

Again, this would be much easier if a function could return a different type predicate for the true and false cases!

That fix seemed to work and all tests pass, so we should be back in business. This is going to be a bit slower than the version that @typescript-bot tested earlier but I'm feeling more confident that it's correct.

@typescript-bot test top200
@typescript-bot user test this
@typescript-bot run dt

@typescript-bot perf test this faster
@typescript-bot pack this

Heya @jakebailey, I've started to run the tarball bundle task on this PR at d0e385e. You can monitor the build here.

Heya @jakebailey, I've started to run the diff-based user code test suite on this PR at d0e385e. You can monitor the build here.

Update: The results are in!

Heya @jakebailey, I've started to run the diff-based top-repos suite on this PR at d0e385e. You can monitor the build here.

Update: The results are in!

Heya @jakebailey, I've started to run the parallelized Definitely Typed test suite on this PR at d0e385e. You can monitor the build here.

Update: The results are in!

Heya @jakebailey, I've started to run the faster perf test suite on this PR at d0e385e. You can monitor the build here.

Update: The results are in!

Hey @jakebailey, 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/159974/artifacts?artifactName=tgz&fileId=6697AFDD16758083B1CD91AF9516D7A3DB7DCC2B13099E445566B57CD913996302&fileName=/typescript-5.5.0-insiders.20240221.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@5.5.0-pr-57465-17".;

@jakebailey Here are the results of running the user test suite comparing main and refs/pull/57465/merge:

There were infrastructure failures potentially unrelated to your change:

• 1 instance of "Package install failed"

Otherwise...

Something interesting changed - please have a look.

@jakebailey
The results of the perf run you requested are in!

Hey @jakebailey, the results of running the DT tests are ready.
There were interesting changes:

Error: 
/home/vsts/work/1/DefinitelyTyped/types/lodash/lodash-tests.ts
  1813:5  error  TypeScript@local expected type to be:
  string[]
got:
  "a"[]  @definitelytyped/expect
  1814:5  error  TypeScript@local expected type to be:
  string[]
got:
  "a"[]  @definitelytyped/expect

✖ 2 problems (2 errors, 0 warnings)

    at combineErrorsAndWarnings (/home/vsts/work/1/DefinitelyTyped/node_modules/.pnpm/@definitelytyped+dtslint@0.2.12_typescript@5.5.0-dev.20240221/node_modules/@definitelytyped/dtslint/dist/index.js:194:28)
    at runTests (/home/vsts/work/1/DefinitelyTyped/node_modules/.pnpm/@definitelytyped+dtslint@0.2.12_typescript@5.5.0-dev.20240221/node_modules/@definitelytyped/dtslint/dist/index.js:186:20)

You can check the log here.

@jakebailey Here are the results of running the top-repos suite comparing main and refs/pull/57465/merge:

Something interesting changed - please have a look.

Some errors reported by the bot could be seen as mistakes in the user's code. Why the result of a array, filtered to be an array of numbers, should be typed as anything else than an array of number ?

Building on top of the current approach, but increasing complexity :

A "read" type and a "write" type, for mutable objects.

The read type would represent the latest known type at a point in the control flow. In the case of the array filter, this would mean "this array can hold strings and numbers, but at this point, it only holds numbers".
The write type is the type as we know it today.

This is clearly a whole new thing.

Bonus : at the end of the function, if the read type is the same as the write type, and the object is returned, then you can infer a type predicate. This part is out of the scope of your current PR, if I understood correctly.

This idea is great! I seem to have come up with an implementation for fallback that doesn't require compilation support.

declare const notMatched: unique symbol
function isWhat<Input = unknown, T = never>(
  match: (input: Input, _: typeof notMatched) => T | typeof notMatched
): (
  (x: Input) => x is [T] extends [Input] ? Input & T : never
) {
  return ((x: any): boolean => {
    try {
      return match(x, notMatched) !== notMatched
    } catch (e) {
      if ([notMatched, void 0, null, TypeError].includes(e as any)) {
        return false
      }
      throw e
    }
  }) as any
}

const strs0 = [1, '1', true].filter(
//    ^? string[]
  isWhat((t, _) => typeof t === 'string' ? t : _)
)

const strs1 = [1, '1', true].filter(
//    ^? string[]
  isWhat(t => {
    if (typeof t === 'string') return t
    throw void 0
  })
)

playground

However, this requires an import. But we can simplify the usage of this function by using webpack or built-in global functions.
If this pull request can be approved, it would be great. However, if it doesn't get approved, I think using this piece of code can still solve the current issue of the awkward usage of is.

@weswigham
The results of the perf run you requested are in!

👍👍

Would it be possible to not infer type predicates if in the greater context it would be better (not produce type errors) not to? For example, the following code no longer typechecks without explicitly annotating the return value of the arrow function as boolean.

function example(list: ReadonlyArray<number | string>): Set<number | string> {
    return new Set(
        list.filter((value) => typeof value !== 'number')
    ).add(42);
}

@MichaelMitchell-at You can eliminate that error by telling TypeScript exactly what sort of Set you want when you construct it:

function example(list: ReadonlyArray<number | string>) {
    return new Set<number | string>(
        list.filter((value) => typeof value !== 'number')
    ).add(42);  // ok
}

@MichaelMitchell-at You can eliminate that error by telling TypeScript exactly what sort of Set you want when you construct it:

Sure, but it seems a bit redundant if the function already has an explicit return type, which should be more the norm with #47947

Would it be possible to not infer type predicates if in the greater context it would be better

Generally, no. This implies an O(2 ^ n) algorithm

This is amazing. When TS5.5 comes out I suppose I'll trawl Stack Overflow for obsolete "you can't do this" or "you have to manually annotate the type guard function" answers and modify them. Great work.

Would it be possible to not infer type predicates if in the greater context it would be better (not produce type errors) not to? For example, the following code no longer typechecks without explicitly annotating the return value of the arrow function as boolean.

function example(list: ReadonlyArray<number | string>): Set<number | string> {
    return new Set(
        list.filter((value) => typeof value !== 'number')
    ).add(42);
}

This is already an error:

new Set([""]).add(42); // Argument of type 'number' is not assignable to parameter of type 'string'.(2345)

Is it already decided into which version it will be included?

5.5, the next version

Playground

I have what I believe to be a common use case that does not appear to be supported and doesn't seem to be mentioned in the limitations or other comments here. I suspect this is a limitation of TypeScript's existing control flow analysis, rather than a specific limitation of this new feature.

I would like to be able to filter an array of objects to only the items where an optional property is present:

type Item = {
  foo?: string;
}
const requireFoo = (item: Item) => item.foo !== undefined;

But the inferred return type of this requireFoo function is just boolean rather than an assertion. The reason seems to be that type guards on a property of an object do not narrow the type of the object itself, even though they do narrow the type of that property when you access it on the object.

A more detailed example:

// Testing for `'foo' in x` will narrow `x` to `Record<"foo", unknown>`.
// However, testing `typeof x.foo === 'string'` will not narrow `x`, even though it does narrow `x.foo`.
function testForFoo(x: unknown) {
  if (x !== null && typeof x === 'object' && 'foo' in x && typeof x.foo === 'string')  {
    console.log(x);
    //          ^?
    console.log(x.foo);
    //            ^?
  }
}

The only current workaround I know of is to make the function's return type a restatement of its implementation in the type system:

type WithRequired<T, K extends keyof T> = T & { [P in K]-?: T[P] };

const requireFoo2 = (item: Item): item is WithRequired<Item, 'foo'> => item.foo !== undefined;

A simpler form is to write

(item: Item): item is Item & { foo: string } =>

i'd love to be able to

Handle multiple returns

this would allow me to do stuff like this, or even a satisfies version of that, to handle (with constant runtime performance, à la switch) an arbitrarily large amount of narrowing cases!

@btoo adding support for multiple returns isn't that difficult. I have a branch that implements it here: main...danvk:TypeScript:multi-return-predicate

There would be a performance impact since this would run on more functions, and it's unclear whether this would infer enough additional type predicates for that to be worthwhile. (I'd put up a PR but I'm getting a new circularity error in emitter.ts — another downside of running on more functions!)