Suggestion: check narrowed type in user-defined type guards

[OliverJAsh]

Search Terms

validate type check user defined guard return narrow

Suggestion

const checkIsNumber = (value: unknown): value is number => typeof value === "string";

This function is invalid because the type specified in the return type (number) does not match the reality at runtime (string). However, TS does not currently throw a type error.

Could TypeScript type check user-defined type guards? Specifically it should check the narrowed type of value in the function body (after all guards) matches the explicit return type.

const checkIsNumber = (value: unknown): value is number =>
  typeof value === "string" &&
  (() => {
    // TS knows here that the type is narrowed to `string`.
    // This does not match the explicit return type of this user-defined type guard (`number`).
    // Therefore, TS could/should error?
    value;

    return typeof value === "string";
  })();

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.

[RyanCavanaugh]

For the most part we don't expect UDTGs to be checkable at all, because that's why the author is writing them in the first place. Trivial type guards which we would be able to check may as well be inlined anyway, and more error-prone type guards wouldn't be checkable anyway.

[OliverJAsh]

that's why the author is writing them in the first place

Not necessarily—sometimes they're written just to abstract checks so we don't have to repeat them. Such is the case with checkIsObject:

const checkIsObject = (value: unknown): value is object =>
  typeof value === 'object' && object !== null;

[dragomirtitian]

@RyanCavanaugh

How about a mode for type guards that asks the compiler to figure out the type of the parameter :

const isNumber = (value: unknown): value is  infer =>
  typeof value === 'number' 

The use case of this is when moving a check the compiler can accurately type to a utility function.

The compiler will determine the type of the specific parameter when the return of the function is true. Most of the machinery to do this is there, I think the one extension would be if the return is an expression, take the expression and figure out the type on the true case and the false case of the expression.

[OliverJAsh]

For anyone who wants to achieve this today, check out fp-ts Option.getRefinement function. Update: blog post https://unsplash.com/blog/user-defined-type-guards-not-safe/

[safareli]

First time I realized type guards were as unsafe as as I was shocked, as a result "invented" something like what fp-ts getRefinement is.

Something like value is infer would be nice 👍

[Lonli-Lokli]

Why there is no validation for typeguards (playground ) ? From my understanding this code should fail in compile time

type WithA = { a?: { someMethod: (x: number) => number } } 

const thingWithA: WithA = { a: undefined };

const typeGuard = (obj: unknown): obj is WithA => {
    return typeof obj === 'object' && obj !== null && 'unknownProp' in obj;
}

[fdcds]

Why there is no validation for typeguards (playground ) ? From my understanding this code should fail in compile time

type WithA = { a?: { someMethod: (x: number) => number } } 

const thingWithA: WithA = { a: undefined };

const typeGuard = (obj: unknown): obj is WithA => {
    return typeof obj === 'object' && obj !== null && 'unknownProp' in obj;
}

I think your example fits the suggestion described in #21732.

[typescript-bot]

This issue has been marked as "Too Complex" and has seen no recent activity. It has been automatically closed for house-keeping purposes.