Infer type predicates from function bodies using control flow analysis by danvk · Pull Request #57465 · microsoft/TypeScript

Dan Vanderkam (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:

functionisString(x: string|number){returntypeofx==='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:

functionf(p: T,p2: T2, ...){// ...returnexpr;}

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

functionf(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:

declarefunctionisString(x: string|number): x is string;

then x is a string if this function returns true. But if it returns false then xmust 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:

functionf(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:

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

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

constfoos=[newFoo(),newBar(),newFoo(),newBar()].filter(x=>xinstanceofFoo);// ^? const foos: Foo[]

There are a few other non-obvious wins:

Type guards now flow

constisString=(o: string|undefined): o is string=>!!o;// - (o: string | undefined) => boolean// + (o: string | undefined) => o is stringconstsecondIsString=(o: string|undefined)=>myGuard(o);

They also compose in new ways:

// const isFooBar: (x: unknown) => x is Foo | BarconstisFooBar=(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:

constnumsTruthy=[0,1,2,null,3].filter(x=>!!x);// ^? const numsTruthy: (number | null)[]constnumsNonNull=[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:

constdatesTruthy=[newDate(),null,newDate(),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:

constisString=(x: unknown)=>typeofx==='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:

interfaceNumberInferrer{isNumber(x: number|string): x is number;}classInferrerimplementsNumberInferrer{isNumber(x: number|string){// this is checked!!!returntypeofx==='number';}}

Interesting cases

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

// boolId: (b: boolean): b is true?constboolId=(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:

functionflakyIsString(x: string|number){returntypeofx==='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>functionhasAB(x: unknown){returnx!==null&&typeofx==='object'&&'a'inx&&'b'inx;}

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:

functionisShortString(x: unknown){returntypeofx==='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:

functionassertAndPredicate(x: string|number|Date){if(xinstanceofDate){thrownewError();}returntypeofx==='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)

consta=[1,"foo",2,"bar"].filter(x=>typeofx==="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 (@typescript-bot) and I have found.

Performance

We're doing additional work to infer type predicates, so performance is certainly a concern. TypeScript Bot (@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

functionisString(x: string|number){if(typeofx==='string'){returntrue;}returnfalse;}

TypeScript Bot (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.

Dan Vanderkam (danvk)

I'll look into the self-check errors.

Dan Vanderkam (danvk) · 2024-02-21T16:58:30Z

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

Dan Vanderkam (danvk) · 2024-02-21T16:59:49Z

+
+// 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.

Dan Vanderkam (danvk) · 2024-02-21T17:02:11Z

 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.

Ryan Cavanaugh (RyanCavanaugh) · 2024-02-21T17:11:57Z

TypeScript Bot (@typescript-bot) perf test this faster

TypeScript Bot (typescript-bot) · 2024-02-21T17:12:01Z

Heya Ryan Cavanaugh (@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!

Bruce Pascoe (fatcerberus) · 2024-02-21T17:25:42Z

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

letisNumberable=(x: string|number)=>typeofx==='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 (typescript-bot) · 2024-02-21T17:48:33Z

Ryan Cavanaugh (@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

Dan Vanderkam (danvk) · 2024-02-21T19:26:46Z

Bruce Pascoe (@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)

consta=[1,"foo",2,"bar"].filter(x=>typeofx==="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.

functionisShortString(x: unknown){returntypeofx==='string'&&x.length<10;}declareletstr: string;if(isShortString(str)){str;// string}else{str;// never}

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

functionisString(x: unknown){returntypeofx==='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.

Bruce Pascoe (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)

Dan Vanderkam (danvk) · 2024-02-21T19:46:00Z

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

Bruce Pascoe (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

Dan Vanderkam (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!

Dan Vanderkam (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 (@typescript-bot)tested earlier but I'm feeling more confident that it's correct.

Jake Bailey (jakebailey) · 2024-02-21T22:59:28Z

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

TypeScript Bot (@typescript-bot) perf test this faster
TypeScript Bot (@typescript-bot) pack this

TypeScript Bot (typescript-bot) · 2024-02-21T22:59:31Z

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

TypeScript Bot (typescript-bot) · 2024-02-21T22:59:31Z

Heya Jake Bailey (@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 (typescript-bot) · 2024-02-21T22:59:31Z

Heya Jake Bailey (@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 (typescript-bot) · 2024-02-21T22:59:31Z

Heya Jake Bailey (@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 (typescript-bot) · 2024-02-21T22:59:31Z

Heya Jake Bailey (@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 (typescript-bot) · 2024-02-21T23:01:40Z

Hey Jake Bailey (@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 (typescript-bot) · 2024-02-21T23:19:34Z

Jake Bailey (@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 (typescript-bot) · 2024-02-21T23:34:26Z

Jake Bailey (@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 (typescript-bot) · 2024-02-21T23:45:13Z

Hey Jake Bailey (@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 (typescript-bot) · 2024-02-22T00:43:46Z

Jake Bailey (@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

Jonathan MASSUCHETTI (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.

YiJie (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.

declareconstnotMatched: unique symbolfunctionisWhat<Input=unknown,T=never>(match: (input: Input,_: typeofnotMatched)=>T|typeofnotMatched): ((x: Input)=>x is [T]extends[Input] ? Input&T : never){return((x: any): boolean=>{try{returnmatch(x,notMatched)!==notMatched}catch(e){if([notMatched,void0,null,TypeError].includes(easany)){returnfalse}throwe}})asany}conststrs0=[1,'1',true].filter(// ^? string[]isWhat((t,_)=>typeoft==='string' ? t : _))conststrs1=[1,'1',true].filter(// ^? string[]isWhat(t=>{if(typeoft==='string')returntthrowvoid0}))

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.

Reece Dunham (RDIL) · 2024-06-22T15:55:12Z

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

Jake Bailey (jakebailey) · 2024-06-22T16:02:23Z

Yes, Boolean is not a type predicate.

Jordan Harband (ljharb) · 2024-06-22T16:14:24Z

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

Joe Calzaretta (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.)

Dan Vanderkam (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.

Xuyang Ge (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:

constisTrue=<T>(o: T|undefined|null|false|0|""): o is T=>!!o;constarray=[0,"",5,"hello",falseasconst,null,undefined]constresult: (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.

Dan Vanderkam (danvk) · 2024-07-10T18:36:58Z

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

constisTrue=<T,>(o: T|undefined|null|false|0|""): o is T=>!!o;letx=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.

Joe Calzaretta (jcalz) · 2024-08-01T12:30:18Z

Yes, we talked about it just a few comments back

Joe Calzaretta (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 (typescript-bot) added the For Uncommitted Bug PR for untriaged, rejected, closed or missing bug label Feb 21, 2024

Run formatter
e2684f1

Dan Vanderkam (danvk) commented Feb 21, 2024
View reviewed changes

Dan Vanderkam (danvk) added 2 commits February 21, 2024 16:16

Add secondary subtype check and tests
101df93

add union type test to baselines
d0e385e

Vincent Driessen (nvie) mentioned this pull request Apr 16, 2024
Enable typed queries for threads liveblocks/liveblocks#1568
Merged

Lachlan Heywood (lachieh) mentioned this pull request Apr 18, 2024
prefer-native-coercion-functions should ignore type guards sindresorhus/eslint-plugin-unicorn#1857
Closed

Lonli-Lokli mentioned this pull request Apr 19, 2024
Accept de-structured elements in type predicates #41173
Open
5 tasks

Alexander (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
Closed
Type predicate assertion does not carry over when used in another function #51326
Closed

Christian Petersen (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

Joe Calzaretta (jcalz) mentioned this pull request Jun 24, 2024
Filter with "something is smallerType" don't work as negative #58996
Closed

Michal Maršálek (MichalMarsalek) mentioned this pull request Jun 24, 2024
Inferred Type Predicates don't work with the Boolean function #58999
Closed

Joe Calzaretta (jcalz) mentioned this pull request Aug 2, 2024
Inferred Type Predicates doesn't narrow type if using other conditional expressions #59509
Closed

Stian Jensen (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

Paul Souche (paulsouche) mentioned this pull request Sep 30, 2024
[Control flow] Array filter with typeguard works differently following array initial value #60108
Open

Emmanuel (emmnull) mentioned this pull request Nov 30, 2024
Proposal: Predicate inferer sindresorhus/type-fest#973
Open
1 task

Joe Calzaretta (jcalz) mentioned this pull request Dec 17, 2024
Refining discriminated union of arrays with array.find on a property that is a union #60785
Closed

Florent BENOIT (benoitf) mentioned this pull request Feb 11, 2025
chore: using simple objects in rpc api (to avoid snapshots) podman-desktop/extension-bootc#1314
Merged

Martin Johns (MartinJohns) mentioned this pull request Feb 15, 2025
Inconsistent inferred type predicate for filter #61182
Closed

Microsoft (microsoft) locked as resolved and limited conversation to collaborators Oct 16, 2025

Uh oh!

Conversation

Dan Vanderkam (danvk) commented Feb 21, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

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

Uh oh!

TypeScript Bot (typescript-bot) commented Feb 21, 2024

Uh oh!

Dan Vanderkam (danvk) left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Ryan Cavanaugh (RyanCavanaugh) commented Feb 21, 2024

Uh oh!

TypeScript Bot (typescript-bot) commented Feb 21, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Bruce Pascoe (fatcerberus) commented Feb 21, 2024

Uh oh!

TypeScript Bot (typescript-bot) commented Feb 21, 2024

tsc

Uh oh!

Dan Vanderkam (danvk) commented Feb 21, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Bruce Pascoe (fatcerberus) commented Feb 21, 2024

Uh oh!

Dan Vanderkam (danvk) commented Feb 21, 2024

Uh oh!

Bruce Pascoe (fatcerberus) commented Feb 21, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Dan Vanderkam (danvk) commented Feb 21, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Dan Vanderkam (danvk) commented Feb 21, 2024

Uh oh!

Jake Bailey (jakebailey) commented Feb 21, 2024

Uh oh!

TypeScript Bot (typescript-bot) commented Feb 21, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TypeScript Bot (typescript-bot) commented Feb 21, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TypeScript Bot (typescript-bot) commented Feb 21, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TypeScript Bot (typescript-bot) commented Feb 21, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TypeScript Bot (typescript-bot) commented Feb 21, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TypeScript Bot (typescript-bot) commented Feb 21, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TypeScript Bot (typescript-bot) commented Feb 21, 2024

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

/mnt/ts_downloads/pyright/build.sh

Uh oh!

TypeScript Bot (typescript-bot) commented Feb 21, 2024

tsc

Uh oh!

Dan Vanderkam (danvk) commented Feb 21, 2024•
edited
Loading

TypeScript Bot (typescript-bot) commented Feb 21, 2024•
edited
Loading

Dan Vanderkam (danvk) commented Feb 21, 2024•
edited
Loading

Bruce Pascoe (fatcerberus) commented Feb 21, 2024•
edited
Loading

Dan Vanderkam (danvk) commented Feb 21, 2024•
edited
Loading

TypeScript Bot (typescript-bot) commented Feb 21, 2024•
edited
Loading

TypeScript Bot (typescript-bot) commented Feb 21, 2024•
edited
Loading

TypeScript Bot (typescript-bot) commented Feb 21, 2024•
edited
Loading

TypeScript Bot (typescript-bot) commented Feb 21, 2024•
edited
Loading

TypeScript Bot (typescript-bot) commented Feb 21, 2024•
edited
Loading

TypeScript Bot (typescript-bot) commented Feb 21, 2024•
edited
Loading

YiJie (NWYLZW) commented Feb 22, 2024•
edited
Loading

leppaott commented Aug 1, 2024•
edited
Loading