Constraints applied by conditional types not considered when checking signatures

[weswigham]

Code

declare function log(msg: string): void;
type EQString<T> = T extends string ? T : never;
function c<T>(x: T | string) {
    const y = x as EQString<T>; // assert stringiness
    return log(y);
}

Expected behavior:
No error.

Actual behavior:

[ts]
Argument of type 'EQString<T>' is not assignable to parameter of type 'string'.
  Type 'T' is not assignable to type 'string'

on y.

[ahejlsberg]

This is actually working as intended. The constraint added to T by the T extends string check is in effect only in the true branch of the conditional type. The T produced by EqString<T> is exactly the same T as was passed in and it doesn't have any new constraints. To get the desired effect you need to return an intersection type:

type EQString<T> = T extends string ? T & string : never;

[weswigham]

Hm. OK. That's not the greatest in the context of using conditionals for control flow narrowing, since it causes you to get intersections instead of constrained generics like you'd expect.

[kpdonn]

@weswigham You very well might already know this, but another way to get your example to work without the intersection is

declare function log(msg: string): void
type MustBeString<T extends string> = T
type EQString<T> = T extends MustBeString<infer U> ? U : never
function c<T>(x: T | string) {
  const y = x as EQString<T> // assert stringiness
  return log(y)
}

[weswigham]

It's a little verbose but it seems like it checks out.

[weswigham]

Erm, doesn't check out too well, in heavy use practice. It may give the result a new constraint on whatever you say, but it forgets its relationship with the original T, which is bad:

declare function log(msg: string): void
type MustBeString<T extends string> = T;
type EQString<T> = T extends MustBeString<infer U> ? U : never
function c<T>(x: T | string) {
  const y = x as EQString<T> // assert stringiness
  return useStringyT(y); /// Noooooooo: Argument of type 'EQString<T>' is not assignable to parameter of type 'T & string'

  function useStringyT(x: T & string) {
      return 0;
  }
}

[weswigham]

sigh just intersecting doesn't quite work either, since, for example, in concrete types ModuleKind.None & number doesn't simplify back to ModuleKind.None.

Replacing the constraint via an infer and then intersecting the original T with the inference kinda works.