Infer arrow function type guard type for specific simple cases

Search Terms

arrow function type guard

Suggestion

Specific simple cases of arrow functions of a single argument should be considered type guards:

const f1 = x => x typeof "string"; // immediately returns a typeof expression with a literal rhs
const f2 = x => x instanceof Foo; // immediately returns an instanceof expression
const f3 = x => x === "foo"; // immediately returns a strict (non-)equality comparison with a literal
const f4 = x => x == null; // immediately returns a non-strict (non-)equality comparison with a null literal
const f5 = x => isFoo(x); // immediately returns another type guard

There are more general requests like https://github.com/microsoft/TypeScript/issues/16069, but I beleive this one should be easier to implement, and it still covers a lot of use cases.

Use Cases

filter with heterogenous arrrays:

// currently: (string | number)[]
// would be: string[]
const a = [1, "foo", 2, "bar"].filter(x => x instanceof "string");

Specifically, filtering out null or undefined elements:

// f: (x: string) => Promise<string | undefined>
const a = await Promise.all(["foo", "bar"].map(f));
const b = a.filter(x => x !== undefined);

Limiting the number of arguments of a more complex type guard:

// isFoo: (x: any, strict?: boolean) => x is Foo
const b1 = a.filter(x => isFoo(x));
const b2 = a.filter(x => isFoo(x, true));

// compare:
const b3 = a.filter(isFoo); // No overload matches this call.

Examples

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, etc.)
• This feature would agree with the rest of TypeScript’s Design Goals.

[PMLP-novo]

I know that this is blocked by introducing breaking changes.

But has anybody a real world example of production code, that would break? It seems like a close to unreachable corner case.

Secondly if somebody where to reach this corner case they could very quickly resolve it and would notice it right away when they upgrade typescript.

This question has been asked so many times and so many people spend time discussing it and having a bad typescript experience.

So I argue that this is a case where the right solution is to introduce a breaking change.

[acutmore]

Personally I don’t feel the desire for type hint syntax.

A new --stictXXXX flag added seems inline with other breaking changes to TS’s type inference. It would be interesting if someone could produce some stats on the number of times this would trigger a breaking change when sampled on a group of open-sources repos, also if the error actually seemed to catch a potential bug.

Anecdotally I have come across code like this a few times:

declare let someArray: (string | null)[];
declare function useString(s: string): void;

someArray
  .filter(v => v !== null)
  .forEach(v => {
     useString(v!); // unnessesary null assertion to stop strictNullError
  });

With added syntax required I can see people still being inclined to continue to just add the null assertion, this new ‘infer type guard’ syntax will possibly be seen as ‘advanced syntax’ that not everyone is aware of.

When code is written in a structured style TS infers the type guard without syntax:

for (const v of someArray) {
    if (v !== null) {
        useString(v); // value is inferred correctly without type syntax
    }
}

This all said, I do feel that the infererence should only be done for inline callbacks where the function lists a type guard as one of the possible parameters. Otherwise I could see it being a performance issue on large code bases.

// no type guard infered
const f = (v: any) => typeof v === 'string;

// type guard infered because of filter's type being:
//   filter<S extends T>(cb: (value: T) => value is S): S[];
arr.filter(v => typeof v === 'string)