[Suggestion] Auto inferred type predicates

[yw662]

Suggestion

🔍 Search Terms

infer, type predicates, type guards, user-defined

List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily and help provide feedback.

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

I am suggesting a new typescript feature to automatically infer a function returning a boolean as a function returning a type predicate.

const a = [1, 2, 3, 'a', 'b', 'c']

const b = a.filter(v => typeof v === 'number')
//    ^? 
const c = a.filter((v): v is number => typeof v === 'number')
//    ^?

If type predicates could be inferred, that const b could hopefully be a number[], the same as const c.

This is possible because typescript already knows that typeof v ==='number' is already a typeof type guard, and the function is returning directly the result of a type guard: which is already a type predicate. Therefore, typescript should be able to know that the returned boolean is a type predicate as well.
The behavior should be a "best effort" or it should only recognize those type guards it knows for sure, to avoid false positives that may break things, since a type guard is not only about "when it is true, v is T", but also a "when it is false, v is not T". (Or could there be half guards like "when it is true, v is T" but "when it is false, v is T or not T" or the opposite ?)

📃 Motivating Example

Array.prototype.filter can already take type guards as input, but users still need to manually write down the predicates. This is boring and risky since typescript will never check those predicates. It is possible to have a false type guard like (v): v is string => typeof v ==='number'.
To simplify such use cases and to eliminate errors related to user-defined type guards, it should be helpful to infer the type predicates from what the function return.

💻 Use Cases

Array.prototype.filter, as mentioned above.
Other use cases for a user-defined type guard.

[fatcerberus]

Duplicate #16069. Note that not every expression that results in a type narrowing maps to a x is Type style predicate.

[yw662]

Note that not every expression that results in a type narrowing...

Yeah that's what I mean "best effort". It can work only on what it knows for sure.

[yw662]

Duplicate #16069.

Yeah but I suggest a specific approach that the type predicate returned from a built-in type guard can be used to type the return value.

[MartinJohns]

Duplicate of #38390.

[typescript-bot]

This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.