infer doesn't work correctly with type predicates

[glevchuk]

Bug Report

🔎 Search Terms

infer type predicates

🕗 Version & Regression Information

• I've tested this in last 4 versions and i've got same behavior

⏯ Playground Link

Playground link with relevant code

💻 Code

interface ResponseError {
  type: string;
  data?: Record<string, string>;
}

interface PaymentError extends ResponseError {
  type: "PaymentError";
  data: { reason: string };
}

const isPaymentError = (error: ResponseError): error is PaymentError =>
  error.type === "PaymentError";

const processErrors = <
  TypeGuard extends (error: ResponseError) => boolean,
  ErrorType = TypeGuard extends (error: ResponseError) => error is infer U
  //  =============================================================^
  // A type predicate's type must be assignable to its parameter's type.
  // Type 'U' is not assignable to type 'ResponseError'.(2677)
    ? U
    : unknown
>(
  errors: ResponseError[],
  typeGuard: TypeGuard,
  callback: (error: ErrorType) => void
) => {};

processErrors(
  [],
  isPaymentError,
  (error) => {
  // ^? (parameter) error: PaymentError
    error.data.reason
    //           ^? (property) reason: string
  }
);

🙁 Actual behavior

Error on infer declaration, but types inferred correctly

🙂 Expected behavior

TypeScript doesn't throw an error

[shicks]

The error is saying that you're not allowed to declare a type guard where the narrowed type is not assignable to the wider type. Here's a simpler example:

function isNumber(x: string): x is number {
  return false;
}

You can fix it in your case by either changing the argument type to unknown:

    ErrorType = TypeGuard extends (error: unknown) => error is infer U

or else using an intersection with the infer:

    ErrorType = TypeGuard extends (error: ResponseError) => error is ResponseError&infer U

There may be a use case where we'd like to be able to put a lower bound on an inferred type variable, but I don't think this is it?

[whzx5byb]

You should declare a constraint for the inferred type:

const processErrors = <
  TypeGuard extends (error: ResponseError) => boolean,
-  ErrorType = TypeGuard extends (error: ResponseError) => error is infer U
+  ErrorType = TypeGuard extends (error: ResponseError) => error is (infer U extends ResponseError)
  //  =============================================================^
  // A type predicate's type must be assignable to its parameter's type.
  // Type 'U' is not assignable to type 'ResponseError'.(2677)
    ? U
    : unknown
>(

[RyanCavanaugh]

@whzx5byb's suggestion is the preferable one

[reverofevil]

not allowed to declare a type guard where the narrowed type is not assignable to the wider type

The type is inferred, not specified. It's assignable or not assignable only due to inner workings of TS's type checker. It was (hopefully) a conscious choice not to put a bound on an inferred type automatically.

error is (infer U extends ResponseError)

Is that a valid syntax? I think it should be error is Extract<infer U, ResponseError>.

[whzx5byb]

Is that a valid syntax?

Yes, it is introduced since 4.7.

[shicks]

not allowed to declare a type guard where the narrowed type is not assignable to the wider type

The type is inferred, not specified. It's assignable or not assignable only due to inner workings of TS's type checker. It was (hopefully) a conscious choice not to put a bound on an inferred type automatically.

I could see it going either way, but it takes a certain amount of smarts to recognize that it's actually OK because the rule about type predicates effectively adds an implicit lower bound on U. It seems quite reasonable that the type checker doesn't have that kind of smarts built in. Though it could be a delightful surprise, and potentially wouldn't cause any unpleasant surprises, if it could do it automatically.

Is that a valid syntax?

Yes, it is introduced since 4.7.

TIL.

[typescript-bot]

This issue has been marked as 'Question' and has seen no recent activity. It has been automatically closed for house-keeping purposes. If you're still waiting on a response, questions are usually better suited to stackoverflow or the TypeScript Discord community.