Repository navigation
Constraints applied by conditional types not considered when checking signatures #22347
Description
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.
Activity
[-]Constraints applied by conditional types not considered when checking signatures[/-][+]Constraints applied by conditional types not considered later in control flow[/+][-]Constraints applied by conditional types not considered later in control flow[/-][+]Constraints applied by conditional types not considered when checking signatures[/+]ahejlsberg commentedon Mar 6, 2018
This is actually working as intended. The constraint added to
Tby theT extends stringcheck is in effect only in the true branch of the conditional type. TheTproduced byEqString<T>is exactly the sameTas was passed in and it doesn't have any new constraints. To get the desired effect you need to return an intersection type:weswigham commentedon Mar 6, 2018
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 commentedon Mar 7, 2018
Wesley Wigham (@weswigham) You very well might already know this, but another way to get your example to work without the intersection is
weswigham commentedon Mar 7, 2018
It's a little verbose but it seems like it checks out.
weswigham commentedon Mar 9, 2018
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:weswigham commentedon Mar 9, 2018
sigh just intersecting doesn't quite work either, since, for example, in concrete types
ModuleKind.None & numberdoesn't simplify back toModuleKind.None.Replacing the constraint via an
inferand then intersecting the originalTwith the inference kinda works.typescript-bot commentedon Mar 23, 2018
Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.