Infer type predicates from function bodies using control flow analysis #57465

danvk · 2024-02-21T16:31:03Z

Fixes #16069
Fixes #38390
Fixes #10734
Fixes #50734
Fixes #12798

This PR uses the TypeScript's existing control flow analysis to infer type predicates for boolean-returning functions where appropriate. For example:

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

This currently has an inferred return type of boolean, but with this PR it becomes a type predicate:

I filed #16069 seven years ago (!) and thought it would be interesting to try and fix it. It turned out to be cleaner and simpler than I thought: only ~65 LOC in one new function. I think it's a nice win!

How this works

A function is a candidate for an inferred type guard if:

It does not have an explicit return type or type predicate.
Its inferred return type is boolean.
It has a single return statement and no implicit returns (this could potentially be relaxed later).
It does not mutate its parameter.

If so, then the function looks something like this:

function f(p: T, p2: T2, ...) {
  // ...
  return expr;
}

For each parameter, this PR determine what its flow type would be in each branch if the function looked like this instead:

function f(p: T, p2: T2, ...) {
  // ...
  if (expr) {
    p1;  // trueType
  }
}

if trueType != T then we have a candidate for a type predicate.

We still need to check what a false return value means because of the semantics of type predicates. If we have:

declare function isString(x: string | number): x is string;

then x is a string if this function returns true. But if it returns false then x must be a number. In other words, in order to be a type predicate, a function should return true if and only if the predicate holds.

We can test this directly by plugging in trueType to the synthesized if statement and seeing what's left in the else branch:

function f(p: trueType, p2: T2, ...) {
  // ...
  if (expr) {
    p1;  // trueType
  } else {
    p1;  // never?
}

If it's never then we've demonstrated the "only if" condition.

Note that the previous versions of this PR did slightly different checks. The original version had problems with subtypes and my initial fix made more calls to getFlowTypeOfReference than was necessary. This version directly tests the condition that we want.

Wins

TypeScript is now able to infer type guards in many places where it's convenient, e.g. calls to filter:

const nums = [12, "foo", 23, "bar"].filter(x => typeof x === 'number');
//    ^? const nums: number[]

Since this piggybacks off of the existing flow type code, all forms of narrowing that TypeScript understands will work.

const foos = [new Foo(), new Bar(), new Foo(), new Bar()].filter(x => x instanceof Foo);
//    ^? const foos: Foo[]

There are a few other non-obvious wins:

Type guards now flow

const isString = (o: string | undefined): o is string => !!o;

// - (o: string | undefined) => boolean
// + (o: string | undefined) => o is string
const secondIsString = (o: string | undefined) => myGuard(o);

They also compose in new ways:

// const isFooBar: (x: unknown) => x is Foo | Bar
const isFooBar = (x: unknown) => isFoo(x) || isBar(x);

This is a gentle nudge away from truthiness footguns

We don't infer a type guard here if you check for truthiness, only if you check for non-nullishness:

const numsTruthy = [0, 1, 2, null, 3].filter(x => !!x);
//    ^? const numsTruthy: (number | null)[]
const numsNonNull = [0, 1, 2, null, 3].filter(x => x !== null);
//    ^? const numsNonNull: number[]

This is because of the false case: if the truthiness test returns false, then x could be 0. Until TypeScript can represent "numbers other than 0" or it has a way to return distinct type predicates for the true and false cases, there's nothing that can be inferred from the truthiness test here.

If you're working with object types, on the other hand, there is no footgun and a truthiness test will infer a predicate:

const datesTruthy = [new Date(), null, new Date(), null].filter(d => !!d);
//    ^? const datesTruthy: Date[]

This provides a tangible incentive to do non-null checks instead of truthiness checks in the cases where you should be doing that anyway, so I call this a win. Notably the example in the original issue tests for truthiness rather than non-null.

Type guards are more discoverable

Type predicates are an incredibly useful feature, but you'd never learn about them without reading the documentation or seeing one in a declaration file. Now you can discover them by inspecting symbols in your own code:

const isString = (x: unknown) => typeof x === 'string';
//     ^? const isString: (x: unknown) => x is string

This makes them feel like they're more a part of the language.

Inferred type guards in interfaces are checked

While this PR defers to explicit type predicates, it will check an inferred predicate in this case:

interface NumberInferrer {
  isNumber(x: number | string): x is number;
}
class Inferrer implements NumberInferrer {
  isNumber(x: number | string) {  // this is checked!!!
    return typeof x === 'number';
  }
}

Interesting cases

The identity function on booleans is, in theory, a type guard:

// boolId: (b: boolean): b is true?
const boolId = (b: boolean) => b;

This seems correct but not very useful: why not just test the boolean? I've specifically prohibited inferring type predicates on boolean parameters in this PR. If nothing else this significantly reduces the number of diffs in the baselines.

Here's another interesting case:

function flakyIsString(x: string | number) {
  return typeof x === 'string' && Math.random() > 0.5;
}

If this returns true then x is a string. But if it returns false then x could still be a string. So it would not be valid to infer a type predicate in this case. This is why we can't just check the trueType. In general, combining conditions like this will prevent inference of a type predicate. It would be nice if there were a way for a function to return distinct type predicates for the true and false cases (#15048). This would make inference much more powerful. But that would be a bigger change.

I remember RyanC saying once that a function's return type shouldn't be a restatement of its implementation in the type system. In some cases this can feel like a move in that direction:

// function hasAB(x: unknown): x is object & Record<"a", unknown> & Record<"b", unknown>
function hasAB(x: unknown) {
  return x !== null && typeof x === 'object' && 'a' in x && 'b' in x;
}

Like any function, a type guard can be called with any subtype of its declared parameter types. We need to consider this when inferring a type guard:

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

The issue here is that x narrows to string and unknown if you inline this check in an if / else, and Exclude<unknown, string> = unknown. But we can't infer a type predicate here because isShortString could be called with a string. This broke the test originally used in this PR, see this comment.

A function could potentially narrow the parameter type before it gets to the return, say via an assertion:

function assertAndPredicate(x: string | number | Date) {
  if (x instanceof Date) {
    throw new Error();
  }
  return typeof x === 'string';
}

It's debatable what we should do in this case. Inferring x is string isn't wrong but will produce imprecise types in the else branch (which will include Date). This PR plays it safe by not inferring a type predicate in this case, at the cost of an extra call to getFlowTypeOfReference.

Breaks to Existing Code

Most new errors in existing code are more or less elaborate variations on #38390 (comment)

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

In other words, this PR allows TS to infer a narrower type for an array or other variable, and then you do something that required the broader type: pushing, reassigning, calling indexOf. See this comment for a full run-down of the changes that @typescript-bot and I have found.

Performance

We're doing additional work to infer type predicates, so performance is certainly a concern. @typescript-bot found the most significant slowdown with Compiler-Unions, a +1.25% increase in Check time.

Some fraction of the slowdown is from additional work being done in getTypePredicateFromBody (my addition), but some is also because TypeScript is inferring more precise types in more places thanks to the newly-detected type guards.

If there are performance concerns with the current implementation, there are a few options for reducing its scope:

Only run this on arrow functions
Only run this on contextually-typed arrow functions
Only run this on contextually-typed arrow functions where the context would use the type predicate (e.g. Array.prototype.filter).

Possible extensions

There are a few possible extensions of this that I've chosen to keep out of scope for this PR:

Check explicit type predicates. This PR defers to explicit type predicates, but you could imagine checking them instead. This would bring some type safety to user-defined type guards, which are currently no safer than type assertions.
Infer assertion functions. If you throw instead of returning a boolean, it should be possible to perform an analogous form of inference. Infer AssertsIdentifier type predicates #58495
If Suggestion: one-sided or fine-grained type guards #15048 were implemented, we could infer type predicates in many, many more situations.
Infer type predicates on this. It's possible for a boolean-returning method to be a this predicate. This should be a straightforward extension of this PR.
Infer type predicates on functions that return something other than boolean. If dates is (Date|null)[], then dates.filter(d => d) is a fine way to filter the nulls. This PR makes you write dates.filter(d => !!d). I believe this is a limitation of type predicates in general, not of this PR.
Handle multiple returns. It should be possible to infer a type guard for this function, for example, but it would require more bookkeeping. Infer type predicates for functions with multiple returns #58154

function isString(x: string | number) {
  if (typeof x === 'string') {
    return true;
  }
  return false;
}

typescript-bot · 2024-02-21T16:31:13Z

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.

danvk

I'll look into the self-check errors.

src/compiler/checker.ts

danvk · 2024-02-21T16:58:30Z

tests/baselines/reference/javascriptThisAssignmentInStaticBlock.errors.txt

This file is deleted because we now (correctly) infer a type guard that's compatible with Array.isArray, which makes the error go away!

danvk · 2024-02-21T16:59:49Z

tests/baselines/reference/inferTypePredicates.types

+
+// String escaping issue (please help!)
+function dunderguard(__x: number | string) {
+>dunderguard : (__x: number | string) => ___x is string


Note the three _s on the type predicate. This is a bug caused by the param.name.escapedText as string type assertion. I'm not sure how to fix it.

src/compiler/checker.ts

danvk · 2024-02-21T17:02:11Z

tests/cases/fourslash/thisPredicateFunctionQuickInfo.ts

@@ -65,5 +65,5 @@ verify.quickInfos({
    7: "(method) GuardInterface.isFollower(): this is FollowerGuard",
    13: "let leaderStatus: boolean",
    14: "let checkedLeaderStatus: boolean",
-    15: "function isLeaderGuard(g: RoyalGuard): boolean"
+    15: "function isLeaderGuard(g: RoyalGuard): g is LeadGuard"


This is correct, a type predicate now flows where it did not before.

RyanCavanaugh · 2024-02-21T17:11:57Z

@typescript-bot perf test this faster

typescript-bot · 2024-02-21T17:12:01Z

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!

fatcerberus · 2024-02-21T17:25:42Z

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).

typescript-bot · 2024-02-21T17:48:33Z

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

Here they are:

tsc

Comparison Report - baseline..pr

_Metric	_baseline	_pr	_Delta	_Best	_Worst	_p-value
_{Angular - node (v18.15.0, x64)}
_{Memory used}	_{295,666k (± 0.01%)}	_{295,656k (± 0.01%)}	_~	_295,638k	_295,678k	_{p=0.630 n=6}
_{Parse Time}	_{2.66s (± 0.24%)}	_{2.66s (± 0.28%)}	_~	_2.65s	_2.67s	_{p=0.718 n=6}
_{Bind Time}	_{0.83s (± 0.99%)}	_{0.83s (± 1.18%)}	_~	_0.82s	_0.85s	_{p=0.383 n=6}
_{Check Time}	_{8.26s (± 0.31%)}	_{8.26s (± 0.52%)}	_~	_8.21s	_8.32s	_{p=0.872 n=6}
_{Emit Time}	_{7.11s (± 0.28%)}	_{7.12s (± 0.35%)}	_~	_7.08s	_7.15s	_{p=0.418 n=6}
_{Total Time}	_{18.86s (± 0.20%)}	_{18.87s (± 0.32%)}	_~	_18.82s	_18.96s	_{p=0.809 n=6}
_{Compiler-Unions - node (v18.15.0, x64)}
_{Memory used}	_{193,496k (± 1.54%)}	_{196,079k (± 1.56%)}	_~	_194,078k	_200,129k	_{p=0.128 n=6}
_{Parse Time}	_{1.36s (± 1.43%)}	_{1.36s (± 1.27%)}	_~	_1.33s	_1.38s	_{p=1.000 n=6}
_{Bind Time}	_{0.72s (± 0.00%)}	_{0.72s (± 0.00%)}	_~	_0.72s	_0.72s	_{p=1.000 n=6}
_{Check Time}	_{9.35s (± 0.47%)}	_{9.71s (± 0.26%)}	_{+0.36s (+ 3.89%)}	_9.69s	_9.76s	_{p=0.005 n=6}
_{Emit Time}	_{2.61s (± 0.47%)}	_{2.66s (± 0.21%)}	_{+0.04s (+ 1.53%)}	_2.65s	_2.66s	_{p=0.004 n=6}
_{Total Time}	_{14.05s (± 0.44%)}	_{14.45s (± 0.28%)}	_{+0.40s (+ 2.88%)}	_14.41s	_14.51s	_{p=0.005 n=6}
_{Monaco - node (v18.15.0, x64)}
_{Memory used}	_{347,475k (± 0.01%)}	_{347,539k (± 0.01%)}	_{+64k (+ 0.02%)}	_347,509k	_347,566k	_{p=0.005 n=6}
_{Parse Time}	_{2.48s (± 0.47%)}	_{2.48s (± 0.66%)}	_~	_2.46s	_2.50s	_{p=0.568 n=6}
_{Bind Time}	_{0.93s (± 0.44%)}	_{0.93s (± 0.00%)}	_~	_0.93s	_0.93s	_{p=0.405 n=6}
_{Check Time}	_{6.92s (± 0.27%)}	_{7.03s (± 0.37%)}	_{+0.11s (+ 1.54%)}	_7.00s	_7.07s	_{p=0.005 n=6}
_{Emit Time}	_{4.04s (± 0.34%)}	_{4.06s (± 0.43%)}	_~	_4.03s	_4.07s	_{p=0.161 n=6}
_{Total Time}	_{14.37s (± 0.12%)}	_{14.50s (± 0.16%)}	_{+0.13s (+ 0.88%)}	_14.47s	_14.53s	_{p=0.005 n=6}
_{TFS - node (v18.15.0, x64)}
_{Memory used}	_{302,868k (± 0.00%)}	_{302,836k (± 0.01%)}	_{-33k (- 0.01%)}	_302,784k	_302,864k	_{p=0.016 n=6}
_{Parse Time}	_{2.02s (± 0.70%)}	_{2.01s (± 0.58%)}	_~	_2.00s	_2.03s	_{p=0.161 n=6}
_{Bind Time}	_{1.00s (± 0.75%)}	_{1.01s (± 0.97%)}	_~	_1.00s	_1.02s	_{p=0.300 n=6}
_{Check Time}	_{6.35s (± 0.31%)}	_{6.34s (± 0.46%)}	_~	_6.29s	_6.37s	_{p=0.627 n=6}
_{Emit Time}	_{3.60s (± 0.29%)}	_{3.59s (± 0.43%)}	_~	_3.57s	_3.60s	_{p=0.797 n=6}
_{Total Time}	_{12.96s (± 0.18%)}	_{12.94s (± 0.23%)}	_~	_12.91s	_12.98s	_{p=0.222 n=6}
_{material-ui - node (v18.15.0, x64)}
_{Memory used}	_{511,290k (± 0.00%)}	_{511,308k (± 0.01%)}	_~	_511,283k	_511,383k	_{p=0.296 n=6}
_{Parse Time}	_{2.66s (± 0.46%)}	_{2.65s (± 0.75%)}	_~	_2.63s	_2.68s	_{p=0.557 n=6}
_{Bind Time}	_{1.00s (± 0.75%)}	_{0.99s (± 0.41%)}	_~	_0.99s	_1.00s	_{p=0.100 n=6}
_{Check Time}	_{17.30s (± 0.67%)}	_{17.32s (± 0.38%)}	_~	_17.19s	_17.36s	_{p=0.467 n=6}
_{Emit Time}	_{0.00s (± 0.00%)}	_{0.00s (± 0.00%)}	_~	_0.00s	_0.00s	_{p=1.000 n=6}
_{Total Time}	_{20.95s (± 0.52%)}	_{20.96s (± 0.32%)}	_~	_20.84s	_21.02s	_{p=0.377 n=6}
_{mui-docs - node (v18.15.0, x64)}
_{Memory used}	_{2,293,373k (± 0.00%)}	_{2,293,569k (± 0.00%)}	_{+196k (+ 0.01%)}	_2,293,468k	_2,293,639k	_{p=0.005 n=6}
_{Parse Time}	_{11.98s (± 0.92%)}	_{11.96s (± 0.69%)}	_~	_11.88s	_12.10s	_{p=0.871 n=6}
_{Bind Time}	_{2.65s (± 0.32%)}	_{2.64s (± 0.31%)}	_~	_2.63s	_2.65s	_{p=1.000 n=6}
_{Check Time}	_{102.52s (± 0.59%)}	_{101.24s (± 0.98%)}	_{-1.29s (- 1.25%)}	_99.81s	_102.66s	_{p=0.045 n=6}
_{Emit Time}	_{0.32s (± 1.28%)}	_{0.32s (± 1.60%)}	_~	_0.32s	_0.33s	_{p=0.114 n=6}
_{Total Time}	_{117.47s (± 0.51%)}	_{116.16s (± 0.89%)}	_{-1.31s (- 1.12%)}	_114.71s	_117.73s	_{p=0.037 n=6}
_{self-build-src - node (v18.15.0, x64)}
_{Memory used}	_{2,413,189k (± 0.02%)}	_{868,471k (± 0.02%)}	_{🟩-1,544,717k (-64.01%)}	_868,289k	_868,849k	_{p=0.005 n=6}
_{Parse Time}	_{4.90s (± 0.79%)}	_{5.50s (± 0.80%)}	_{🔻+0.60s (+12.27%)}	_5.45s	_5.57s	_{p=0.005 n=6}
_{Bind Time}	_{1.86s (± 0.92%)}	_{2.34s (± 0.36%)}	_{🔻+0.48s (+25.96%)}	_2.34s	_2.36s	_{p=0.004 n=6}
_{Check Time}	_{33.63s (± 0.43%)}	_{15.99s (± 0.39%)}	_{🟩-17.64s (-52.45%)}	_15.90s	_16.08s	_{p=0.005 n=6}
_{Emit Time}	_{2.68s (± 1.18%)}	_{0.03s (± 0.00%)}	_{🟩-2.65s (-98.88%)}	_0.03s	_0.03s	_{p=0.003 n=6}
_{Total Time}	_{43.08s (± 0.46%)}	_{23.88s (± 0.36%)}	_{🟩-19.20s (-44.57%)}	_23.80s	_24.04s	_{p=0.005 n=6}
_{self-compiler - node (v18.15.0, x64)}
_{Memory used}	_{418,962k (± 0.01%)}	_{414,976k (± 0.01%)}	_{-3,986k (- 0.95%)}	_414,938k	_415,064k	_{p=0.005 n=6}
_{Parse Time}	_{2.82s (± 2.15%)}	_{2.79s (± 3.64%)}	_~	_2.63s	_2.90s	_{p=0.256 n=6}
_{Bind Time}	_{1.10s (± 5.27%)}	_{1.12s (± 5.76%)}	_~	_1.08s	_1.21s	_{p=0.505 n=6}
_{Check Time}	_{15.19s (± 0.25%)}	_{15.44s (± 0.28%)}	_{+0.26s (+ 1.69%)}	_15.40s	_15.52s	_{p=0.005 n=6}
_{Emit Time}	_{1.13s (± 0.67%)}	_{0.02s (±18.82%)}	_{🟩-1.11s (-98.08%)}	_0.02s	_0.03s	_{p=0.003 n=6}
_{Total Time}	_{20.23s (± 0.19%)}	_{19.37s (± 0.27%)}	_{🟩-0.86s (- 4.27%)}	_19.31s	_19.45s	_{p=0.005 n=6}
_{vscode - node (v18.15.0, x64)}
_{Memory used}	_{2,847,216k (± 0.00%)}	_{2,847,890k (± 0.00%)}	_{+674k (+ 0.02%)}	_2,847,837k	_2,848,034k	_{p=0.005 n=6}
_{Parse Time}	_{10.78s (± 0.70%)}	_{10.74s (± 0.43%)}	_~	_10.70s	_10.83s	_{p=0.466 n=6}
_{Bind Time}	_{3.43s (± 0.29%)}	_{3.43s (± 0.62%)}	_~	_3.41s	_3.47s	_{p=0.402 n=6}
_{Check Time}	_{60.82s (± 0.46%)}	_{60.87s (± 0.37%)}	_~	_60.50s	_61.15s	_{p=0.873 n=6}
_{Emit Time}	_{16.90s (± 8.34%)}	_{16.27s (± 0.42%)}	_~	_16.16s	_16.36s	_{p=0.126 n=6}
_{Total Time}	_{91.93s (± 1.77%)}	_{91.31s (± 0.26%)}	_~	_90.93s	_91.58s	_{p=0.689 n=6}
_{webpack - node (v18.15.0, x64)}
_{Memory used}	_{395,919k (± 0.01%)}	_{396,017k (± 0.01%)}	_{+98k (+ 0.02%)}	_395,982k	_396,095k	_{p=0.005 n=6}
_{Parse Time}	_{3.12s (± 0.33%)}	_{3.13s (± 0.26%)}	_~	_3.12s	_3.14s	_{p=0.112 n=6}
_{Bind Time}	_{1.40s (± 0.58%)}	_{1.40s (± 0.37%)}	_~	_1.39s	_1.40s	_{p=0.752 n=6}
_{Check Time}	_{14.02s (± 0.35%)}	_{14.13s (± 0.24%)}	_{+0.10s (+ 0.74%)}	_14.08s	_14.18s	_{p=0.006 n=6}
_{Emit Time}	_{0.00s (± 0.00%)}	_{0.00s (± 0.00%)}	_~	_0.00s	_0.00s	_{p=1.000 n=6}
_{Total Time}	_{18.55s (± 0.27%)}	_{18.66s (± 0.23%)}	_{+0.11s (+ 0.62%)}	_18.60s	_18.72s	_{p=0.005 n=6}
_{xstate - node (v18.15.0, x64)}
_{Memory used}	_{513,455k (± 0.01%)}	_{513,468k (± 0.01%)}	_~	_513,404k	_513,507k	_{p=0.630 n=6}
_{Parse Time}	_{3.28s (± 0.37%)}	_{3.28s (± 0.19%)}	_~	_3.27s	_3.29s	_{p=0.403 n=6}
_{Bind Time}	_{1.54s (± 0.71%)}	_{1.54s (± 0.49%)}	_~	_1.53s	_1.55s	_{p=0.604 n=6}
_{Check Time}	_{2.87s (± 1.06%)}	_{2.85s (± 0.89%)}	_~	_2.82s	_2.89s	_{p=0.258 n=6}
_{Emit Time}	_{0.08s (± 4.99%)}	_{0.07s (± 0.00%)}	_{🟩-0.01s (-14.29%)}	_0.07s	_0.07s	_{p=0.002 n=6}
_{Total Time}	_{7.77s (± 0.45%)}	_{7.75s (± 0.40%)}	_~	_7.72s	_7.80s	_{p=0.334 n=6}

System info unknown

Hosts

node (v18.15.0, x64)

Scenarios

Angular - node (v18.15.0, x64)
Compiler-Unions - node (v18.15.0, x64)
Monaco - node (v18.15.0, x64)
TFS - node (v18.15.0, x64)
material-ui - node (v18.15.0, x64)
mui-docs - node (v18.15.0, x64)
self-build-src - node (v18.15.0, x64)
self-compiler - node (v18.15.0, x64)
vscode - node (v18.15.0, x64)
webpack - node (v18.15.0, x64)
xstate - node (v18.15.0, x64)

_Benchmark	_Name	_Iterations
_Current	_pr	₆
_Baseline	_baseline	₆

Developer Information:

Download Benchmarks

danvk · 2024-02-21T19:26:46Z

@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.

fatcerberus · 2024-02-21T19:45:05Z

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)

danvk · 2024-02-21T19:46:00Z

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

fatcerberus · 2024-02-21T19:53:41Z

~~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

danvk · 2024-02-21T20:36:37Z

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!

danvk · 2024-02-21T22:58:25Z

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.

jakebailey · 2024-02-21T22:59:28Z

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

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

typescript-bot · 2024-02-21T22:59:31Z

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

typescript-bot · 2024-02-21T22:59:31Z

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!

typescript-bot · 2024-02-21T22:59:31Z

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!

typescript-bot · 2024-02-21T22:59:31Z

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!

typescript-bot · 2024-02-21T22:59:31Z

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!

typescript-bot · 2024-02-21T23:01:40Z

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".;

typescript-bot · 2024-02-21T23:19:34Z

@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.

Details

follow-redirects

/mnt/ts_downloads/follow-redirects/tsconfig.json

[NEW] error TS2345: Argument of type 'string | String' is not assignable to parameter of type 'string'.
- /mnt/ts_downloads/follow-redirects/node_modules/follow-redirects/index.js(651,66)

puppeteer

packages/browsers/test/src/tsconfig.json

[MISSING] error TS2307: Cannot find module '@pptr/testserver' or its corresponding type declarations.
- packages/browsers/test/src/utils.ts#L13 in packages/browsers/test/src/tsconfig.json

pyright

/mnt/ts_downloads/pyright/build.sh

[NEW] error TS2339: Property 'nodeType' does not exist on type 'never'.
- /mnt/ts_downloads/pyright/pyright: ../pyright-internal/src/analyzer/testWalker.ts(78,47)
- /mnt/ts_downloads/pyright/pyright-internal: src/analyzer/testWalker.ts(78,47)
- /mnt/ts_downloads/pyright/vscode-pyright: ../pyright-internal/src/analyzer/testWalker.ts(78,47)

typescript-bot · 2024-02-21T23:34:26Z

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

Here they are:

tsc

Comparison Report - baseline..pr

_Metric	_baseline	_pr	_Delta	_Best	_Worst	_p-value
_{Angular - node (v18.15.0, x64)}
_{Memory used}	_{295,649k (± 0.01%)}	_{295,682k (± 0.01%)}	_~	_295,641k	_295,730k	_{p=0.109 n=6}
_{Parse Time}	_{2.66s (± 0.15%)}	_{2.67s (± 0.21%)}	_~	_2.66s	_2.67s	_{p=0.282 n=6}
_{Bind Time}	_{0.83s (± 0.49%)}	_{0.84s (± 0.97%)}	_~	_0.83s	_0.85s	_{p=0.056 n=6}
_{Check Time}	_{8.26s (± 0.44%)}	_{8.28s (± 0.31%)}	_~	_8.26s	_8.33s	_{p=0.328 n=6}
_{Emit Time}	_{7.12s (± 0.09%)}	_{7.12s (± 0.25%)}	_~	_7.09s	_7.14s	_{p=0.737 n=6}
_{Total Time}	_{18.87s (± 0.19%)}	_{18.90s (± 0.19%)}	_~	_18.87s	_18.97s	_{p=0.291 n=6}
_{Compiler-Unions - node (v18.15.0, x64)}
_{Memory used}	_{191,595k (± 0.02%)}	_{195,558k (± 1.26%)}	_{+3,962k (+ 2.07%)}	_194,102k	_200,105k	_{p=0.005 n=6}
_{Parse Time}	_{1.36s (± 0.80%)}	_{1.35s (± 2.08%)}	_~	_1.32s	_1.39s	_{p=0.453 n=6}
_{Bind Time}	_{0.72s (± 0.00%)}	_{0.72s (± 0.00%)}	_~	_0.72s	_0.72s	_{p=1.000 n=6}
_{Check Time}	_{9.36s (± 0.46%)}	_{9.78s (± 0.80%)}	_{🔻+0.42s (+ 4.45%)}	_9.70s	_9.93s	_{p=0.005 n=6}
_{Emit Time}	_{2.62s (± 0.76%)}	_{2.65s (± 1.03%)}	_~	_2.62s	_2.69s	_{p=0.053 n=6}
_{Total Time}	_{14.07s (± 0.28%)}	_{14.50s (± 0.56%)}	_{+0.44s (+ 3.10%)}	_14.44s	_14.66s	_{p=0.005 n=6}
_{Monaco - node (v18.15.0, x64)}
_{Memory used}	_{347,461k (± 0.00%)}	_{347,527k (± 0.00%)}	_{+67k (+ 0.02%)}	_347,514k	_347,543k	_{p=0.005 n=6}
_{Parse Time}	_{2.48s (± 0.71%)}	_{2.48s (± 0.49%)}	_~	_2.46s	_2.49s	_{p=0.280 n=6}
_{Bind Time}	_{0.93s (± 0.44%)}	_{0.93s (± 0.44%)}	_~	_0.92s	_0.93s	_{p=1.000 n=6}
_{Check Time}	_{6.96s (± 0.66%)}	_{7.05s (± 0.59%)}	_{+0.09s (+ 1.32%)}	_7.00s	_7.11s	_{p=0.020 n=6}
_{Emit Time}	_{4.06s (± 0.46%)}	_{4.06s (± 0.53%)}	_~	_4.04s	_4.10s	_{p=0.683 n=6}
_{Total Time}	_{14.42s (± 0.40%)}	_{14.53s (± 0.20%)}	_{+0.11s (+ 0.76%)}	_14.48s	_14.56s	_{p=0.010 n=6}
_{TFS - node (v18.15.0, x64)}
_{Memory used}	_{302,868k (± 0.01%)}	_{302,848k (± 0.00%)}	_~	_302,837k	_302,857k	_{p=0.065 n=6}
_{Parse Time}	_{2.01s (± 1.33%)}	_{2.01s (± 0.96%)}	_~	_1.99s	_2.04s	_{p=0.934 n=6}
_{Bind Time}	_{1.00s (± 1.47%)}	_{1.01s (± 0.81%)}	_~	_1.00s	_1.02s	_{p=0.284 n=6}
_{Check Time}	_{6.36s (± 0.30%)}	_{6.33s (± 0.42%)}	_~	_6.29s	_6.37s	_{p=0.139 n=6}
_{Emit Time}	_{3.58s (± 0.33%)}	_{3.60s (± 0.27%)}	_{+0.02s (+ 0.56%)}	_3.58s	_3.61s	_{p=0.023 n=6}
_{Total Time}	_{12.95s (± 0.24%)}	_{12.95s (± 0.24%)}	_~	_12.90s	_12.99s	_{p=0.872 n=6}
_{material-ui - node (v18.15.0, x64)}
_{Memory used}	_{511,290k (± 0.00%)}	_{511,320k (± 0.01%)}	_~	_511,275k	_511,465k	_{p=0.689 n=6}
_{Parse Time}	_{2.65s (± 0.66%)}	_{2.65s (± 0.55%)}	_~	_2.63s	_2.67s	_{p=0.510 n=6}
_{Bind Time}	_{1.00s (± 0.55%)}	_{0.99s (± 1.11%)}	_~	_0.98s	_1.01s	_{p=0.227 n=6}
_{Check Time}	_{17.30s (± 0.43%)}	_{17.32s (± 0.37%)}	_~	_17.20s	_17.37s	_{p=0.629 n=6}
_{Emit Time}	_{0.00s (± 0.00%)}	_{0.00s (± 0.00%)}	_~	_0.00s	_0.00s	_{p=1.000 n=6}
_{Total Time}	_{20.94s (± 0.40%)}	_{20.96s (± 0.31%)}	_~	_20.84s	_21.03s	_{p=0.378 n=6}
_{mui-docs - node (v18.15.0, x64)}
_{Memory used}	_{2,293,496k (± 0.00%)}	_{2,293,665k (± 0.00%)}	_{+169k (+ 0.01%)}	_2,293,606k	_2,293,713k	_{p=0.005 n=6}
_{Parse Time}	_{11.97s (± 0.86%)}	_{11.96s (± 1.02%)}	_~	_11.85s	_12.17s	_{p=0.808 n=6}
_{Bind Time}	_{2.64s (± 0.50%)}	_{2.64s (± 0.15%)}	_~	_2.63s	_2.64s	_{p=0.446 n=6}
_{Check Time}	_{102.54s (± 0.61%)}	_{101.79s (± 0.85%)}	_~	_100.66s	_102.72s	_{p=0.109 n=6}
_{Emit Time}	_{0.32s (± 1.28%)}	_{0.32s (± 0.00%)}	_~	_0.32s	_0.32s	_{p=0.405 n=6}
_{Total Time}	_{117.47s (± 0.50%)}	_{116.70s (± 0.79%)}	_~	_115.57s	_117.84s	_{p=0.128 n=6}
_{self-build-src - node (v18.15.0, x64)}
_{Memory used}	_{2,413,290k (± 0.02%)}	_{2,415,358k (± 0.02%)}	_{+2,068k (+ 0.09%)}	_2,414,631k	_2,415,917k	_{p=0.005 n=6}
_{Parse Time}	_{4.92s (± 0.70%)}	_{4.91s (± 1.03%)}	_~	_4.82s	_4.97s	_{p=1.000 n=6}
_{Bind Time}	_{1.86s (± 0.74%)}	_{1.87s (± 0.76%)}	_~	_1.85s	_1.89s	_{p=0.101 n=6}
_{Check Time}	_{33.62s (± 0.34%)}	_{33.60s (± 0.45%)}	_~	_33.46s	_33.89s	_{p=0.471 n=6}
_{Emit Time}	_{2.72s (± 1.73%)}	_{2.69s (± 1.09%)}	_~	_2.66s	_2.73s	_{p=0.197 n=6}
_{Total Time}	_{43.14s (± 0.25%)}	_{43.10s (± 0.39%)}	_~	_42.93s	_43.38s	_{p=0.689 n=6}
_{self-compiler - node (v18.15.0, x64)}
_{Memory used}	_{418,986k (± 0.02%)}	_{419,551k (± 0.01%)}	_{+565k (+ 0.13%)}	_419,479k	_419,588k	_{p=0.005 n=6}
_{Parse Time}	_{2.85s (± 0.65%)}	_{2.80s (± 2.36%)}	_~	_2.67s	_2.85s	_{p=0.059 n=6}
_{Bind Time}	_{1.08s (± 0.51%)}	_{1.10s (± 5.36%)}	_~	_1.07s	_1.22s	_{p=0.476 n=6}
_{Check Time}	_{15.16s (± 0.35%)}	_{15.38s (± 0.25%)}	_{+0.22s (+ 1.44%)}	_15.31s	_15.42s	_{p=0.005 n=6}
_{Emit Time}	_{1.14s (± 1.02%)}	_{1.13s (± 1.12%)}	_~	_1.12s	_1.15s	_{p=0.140 n=6}
_{Total Time}	_{20.22s (± 0.19%)}	_{20.41s (± 0.21%)}	_{+0.19s (+ 0.95%)}	_20.34s	_20.45s	_{p=0.005 n=6}
_{vscode - node (v18.15.0, x64)}
_{Memory used}	_{2,847,902k (± 0.00%)}	_{2,848,336k (± 0.00%)}	_{+434k (+ 0.02%)}	_2,848,193k	_2,848,399k	_{p=0.005 n=6}
_{Parse Time}	_{10.74s (± 0.35%)}	_{10.76s (± 0.36%)}	_~	_10.71s	_10.81s	_{p=0.470 n=6}
_{Bind Time}	_{3.43s (± 0.40%)}	_{3.43s (± 0.24%)}	_~	_3.42s	_3.44s	_{p=0.933 n=6}
_{Check Time}	_{60.65s (± 0.90%)}	_{60.85s (± 0.19%)}	_~	_60.63s	_60.97s	_{p=0.092 n=6}
_{Emit Time}	_{16.31s (± 0.60%)}	_{16.28s (± 0.59%)}	_~	_16.17s	_16.42s	_{p=0.521 n=6}
_{Total Time}	_{91.13s (± 0.63%)}	_{91.32s (± 0.19%)}	_~	_91.06s	_91.54s	_{p=0.149 n=6}
_{webpack - node (v18.15.0, x64)}
_{Memory used}	_{395,939k (± 0.02%)}	_{396,031k (± 0.01%)}	_{+92k (+ 0.02%)}	_395,955k	_396,088k	_{p=0.020 n=6}
_{Parse Time}	_{3.11s (± 1.07%)}	_{3.13s (± 0.77%)}	_~	_3.10s	_3.16s	_{p=0.418 n=6}
_{Bind Time}	_{1.40s (± 0.54%)}	_{1.40s (± 0.84%)}	_~	_1.38s	_1.41s	_{p=0.933 n=6}
_{Check Time}	_{14.05s (± 0.40%)}	_{14.15s (± 0.19%)}	_{+0.10s (+ 0.72%)}	_14.12s	_14.20s	_{p=0.005 n=6}
_{Emit Time}	_{0.00s (± 0.00%)}	_{0.00s (± 0.00%)}	_~	_0.00s	_0.00s	_{p=1.000 n=6}
_{Total Time}	_{18.56s (± 0.36%)}	_{18.68s (± 0.25%)}	_{+0.12s (+ 0.64%)}	_18.62s	_18.76s	_{p=0.010 n=6}
_{xstate - node (v18.15.0, x64)}
_{Memory used}	_{513,416k (± 0.00%)}	_{513,441k (± 0.01%)}	_~	_513,364k	_513,501k	_{p=0.173 n=6}
_{Parse Time}	_{3.28s (± 0.26%)}	_{3.28s (± 0.16%)}	_~	_3.27s	_3.28s	_{p=0.533 n=6}
_{Bind Time}	_{1.54s (± 0.26%)}	_{1.54s (± 0.00%)}	_~	_1.54s	_1.54s	_{p=0.405 n=6}
_{Check Time}	_{2.88s (± 1.03%)}	_{2.84s (± 0.68%)}	_{-0.04s (- 1.45%)}	_2.82s	_2.87s	_{p=0.037 n=6}
_{Emit Time}	_{0.08s (± 4.99%)}	_{0.07s (± 5.69%)}	_{🟩-0.01s (-12.24%)}	_0.07s	_0.08s	_{p=0.008 n=6}
_{Total Time}	_{7.78s (± 0.38%)}	_{7.73s (± 0.24%)}	_{-0.05s (- 0.64%)}	_7.72s	_7.77s	_{p=0.013 n=6}

System info unknown

Hosts

node (v18.15.0, x64)

Scenarios

Angular - node (v18.15.0, x64)
Compiler-Unions - node (v18.15.0, x64)
Monaco - node (v18.15.0, x64)
TFS - node (v18.15.0, x64)
material-ui - node (v18.15.0, x64)
mui-docs - node (v18.15.0, x64)
self-build-src - node (v18.15.0, x64)
self-compiler - node (v18.15.0, x64)
vscode - node (v18.15.0, x64)
webpack - node (v18.15.0, x64)
xstate - node (v18.15.0, x64)

_Benchmark	_Name	_Iterations
_Current	_pr	₆
_Baseline	_baseline	₆

Developer Information:

Download Benchmarks

typescript-bot · 2024-02-21T23:45:13Z

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

Branch only errors:

Package: lodash
Error:

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.

typescript-bot · 2024-02-22T00:43:46Z

@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.

Details

microsoft/vscode

3 of 54 projects failed to build with the old tsc and were ignored

src/tsconfig.json

error TS2345: Argument of type 'ChatTreeItem' is not assignable to parameter of type 'IChatResponseViewModel'.
- src/vs/workbench/contrib/chat/browser/chatWidget.ts#L240

src/tsconfig.tsec.json

error TS2345: Argument of type 'ChatTreeItem' is not assignable to parameter of type 'IChatResponseViewModel'.
- src/vs/workbench/contrib/chat/browser/chatWidget.ts#L240

prisma/prisma

80 of 115 projects failed to build with the old tsc and were ignored

packages/client/tsconfig.build.json

error TS2502: 'client' is referenced directly or indirectly in its own type annotation.
- packages/client/src/runtime/core/model/applyModelsAndClientExtensions.ts#L25
- packages/client/src/runtime/core/model/applyModelsAndClientExtensions.ts#L38
error TS2456: Type alias 'Client' circularly references itself.
- packages/client/src/runtime/getPrismaClient.ts#L314

JesusTheHun · 2024-02-22T01:30:33Z

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.

NWYLZW · 2024-02-22T09:14:08Z

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.

btoo · 2024-04-10T19:56:07Z

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!

Edit: @danvk is working on it over at #58154

danvk · 2024-04-10T22:04:59Z

@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!) This is up at #58154.

RDIL · 2024-06-22T15:55:12Z

Hi, is it intentional that this doesn't work using .filter(Boolean)?

jakebailey · 2024-06-22T16:02:23Z

Yes, Boolean is not a type predicate.

ljharb · 2024-06-22T16:14:24Z

I would expect it to behave identically to x => !!x, since that’s what it does

jcalz · 2024-06-22T19:57:01Z

Boolean as a type predicate is #16655 and unrelated to this feature (Boolean is not implemented in TypeScript, so TypeScript does not even have a chance to infer its return type as a type predicate. Instead, Boolean is just declared as something returning boolean. If it were declared to return a type predicate, then .filter(Boolean) would narrow in TS5.4 and below.)

danvk · 2024-06-22T20:32:07Z

If it were declared to return a type predicate, then .filter(Boolean) would narrow in TS5.4 and below.)

In particular, see #50387 (comment) for an explanation of why this would have some surprising negative consequences.

dest1n1s · 2024-07-10T18:29:29Z

I'm feeling a bit confused about why a type guard for truthiness checking could not be performed. Currently I can filter out false types by manually add:

const isTrue = <T>(o: T | undefined | null | false | 0 | ""): o is T => !!o;

const array = [0, "", 5, "hello", false as const, null, undefined]
const result: (string | number)[] = array.filter(isTrue)

but not with array.filter(v => !!v). Despite the fact that the above approach could not express that elements in result could not be "" or 0, it at least filters out false, null and undefined. It seems better to make v => !!v work the same as isTrue.

danvk · 2024-07-10T18:36:58Z

@dest1n1s that version of isTrue should not be a type guard because it can lead to unsound types in the false case:

const isTrue = <T,>(o: T | undefined | null | false | 0 | ""): o is T => !!o;

let x = Math.random() > 0.5 ? 1 : 0;
if (isTrue(x)) {
    x  // number -- ok
} else {
    x  // never -- wrong! could be 0!
}

See my blog post, The The Hidden Side of Type Predicates. To safely infer a type guard for x => !!x for primitive types, we'd either need negated types or #15048.

leppaott · 2024-08-01T11:12:53Z

.filter((uuid) => uuid !== undefined)
// works

.filter((uuid) => uuid)
// doesn't work

.filter(Boolean)
// doesn't work

Any explanation why Boolean doesn't work? I see Boolean discussion how about just uuid i..e that can't be used also would filter zero-length strings.

jcalz · 2024-08-01T12:30:18Z

Yes, we talked about it just a few comments back

jcalz · 2024-08-26T19:42:26Z

Cross-linking to #42384 (feature request to narrow parent object by property guard)

Infer type predicates from function bodies

0c24ccc

typescript-bot added the For Uncommitted Bug PR for untriaged, rejected, closed or missing bug label Feb 21, 2024

Run formatter

e2684f1

danvk commented Feb 21, 2024

View reviewed changes

danvk added 2 commits February 21, 2024 16:16

Add secondary subtype check and tests

101df93

add union type test to baselines

d0e385e

danielattilasimon mentioned this pull request Apr 11, 2024

Deploy the contracts + app together liquity/bold#107

Merged

1 task

sinclairzx81 mentioned this pull request Apr 11, 2024

feedback on Refinement API sinclairzx81/typebox#821

Closed

danvk mentioned this pull request Apr 11, 2024

Infer type predicates for functions with multiple returns #58154

Open

nvie mentioned this pull request Apr 16, 2024

Enable typed queries for threads liveblocks/liveblocks#1568

Merged

lachieh mentioned this pull request Apr 18, 2024

prefer-native-coercion-functions should ignore type guards sindresorhus/eslint-plugin-unicorn#1857

Open

Lonli-Lokli mentioned this pull request Apr 19, 2024

Accept de-structured elements in type predicates #41173

Open

5 tasks

Arctomachine mentioned this pull request May 7, 2024

Trade-offs in Control Flow Analysis #9998

Open

This was referenced May 10, 2024

Regression in detecting unused parameters in 5.5.0-beta #58493

Closed

Infer AssertsIdentifier type predicates #58495

Open

Type predicate assertion does not carry over when used in another function #51326

Closed

fnky mentioned this pull request Jun 21, 2024

Predicate inference fails for empty object and nullish values #58967

Closed

whzx5byb mentioned this pull request Jun 24, 2024

Array filter() by element constructor returns never[] #58987

Closed

jcalz mentioned this pull request Jun 24, 2024

Filter with "something is smallerType" don't work as negative #58996

Open

MichalMarsalek mentioned this pull request Jun 24, 2024

Inferred Type Predicates don't work with the Boolean function #58999

Closed

jcalz mentioned this pull request Aug 2, 2024

Inferred Type Predicates doesn't narrow type if using other conditional expressions #59509

Closed

stianjensen mentioned this pull request Aug 6, 2024

Bug:Lots of Found an "error" any type after upgrade to TypeScript 5.5 typescript-eslint/typescript-eslint#9736

Closed

4 tasks

Lonli-Lokli mentioned this pull request Sep 16, 2024

Allow intersection type guards for multiple parameters #26916

Open

4 tasks

paulsouche mentioned this pull request Sep 30, 2024

[Control flow] Array filter with typeguard works differently following array initial value #60108

Open

Infer type predicates from function bodies using control flow analysis #57465

Infer type predicates from function bodies using control flow analysis #57465

Conversation

danvk commented Feb 21, 2024 • edited Loading

How this works

Wins

Type guards now flow

This is a gentle nudge away from truthiness footguns

Type guards are more discoverable

Inferred type guards in interfaces are checked

Interesting cases

Breaks to Existing Code

Performance

Possible extensions

typescript-bot commented Feb 21, 2024

danvk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RyanCavanaugh commented Feb 21, 2024

typescript-bot commented Feb 21, 2024 • edited Loading

fatcerberus commented Feb 21, 2024

typescript-bot commented Feb 21, 2024

tsc

danvk commented Feb 21, 2024 • edited Loading

fatcerberus commented Feb 21, 2024

danvk commented Feb 21, 2024

fatcerberus commented Feb 21, 2024 • edited Loading

danvk commented Feb 21, 2024 • edited Loading

danvk commented Feb 21, 2024

jakebailey commented Feb 21, 2024

typescript-bot commented Feb 21, 2024 • edited Loading

typescript-bot commented Feb 21, 2024 • edited Loading

typescript-bot commented Feb 21, 2024 • edited Loading

typescript-bot commented Feb 21, 2024 • edited Loading

typescript-bot commented Feb 21, 2024 • edited Loading

typescript-bot commented Feb 21, 2024 • edited Loading

typescript-bot commented Feb 21, 2024

/mnt/ts_downloads/follow-redirects/tsconfig.json

/mnt/ts_downloads/pyright/build.sh

typescript-bot commented Feb 21, 2024

tsc

typescript-bot commented Feb 21, 2024

typescript-bot commented Feb 22, 2024

JesusTheHun commented Feb 22, 2024

NWYLZW commented Feb 22, 2024 • edited Loading

btoo commented Apr 10, 2024 • edited Loading

danvk commented Apr 10, 2024 • edited Loading

RDIL commented Jun 22, 2024

jakebailey commented Jun 22, 2024

ljharb commented Jun 22, 2024

jcalz commented Jun 22, 2024

danvk commented Jun 22, 2024

dest1n1s commented Jul 10, 2024

danvk commented Jul 10, 2024

leppaott commented Aug 1, 2024 • edited Loading

jcalz commented Aug 1, 2024

jcalz commented Aug 26, 2024

danvk commented Feb 21, 2024 •

edited

Loading

typescript-bot commented Feb 21, 2024 •

edited

Loading

danvk commented Feb 21, 2024 •

edited

Loading

fatcerberus commented Feb 21, 2024 •

edited

Loading

danvk commented Feb 21, 2024 •

edited

Loading

typescript-bot commented Feb 21, 2024 •

edited

Loading

typescript-bot commented Feb 21, 2024 •

edited

Loading

typescript-bot commented Feb 21, 2024 •

edited

Loading

typescript-bot commented Feb 21, 2024 •

edited

Loading

typescript-bot commented Feb 21, 2024 •

edited

Loading

typescript-bot commented Feb 21, 2024 •

edited

Loading

NWYLZW commented Feb 22, 2024 •

edited

Loading

btoo commented Apr 10, 2024 •

edited

Loading

danvk commented Apr 10, 2024 •

edited

Loading

leppaott commented Aug 1, 2024 •

edited

Loading