Type narrowing of generic types in control flow analysis

[adrienharnay]

Bug Report

Hello,

🔎 Search Terms

type narrowing, generic types, control flow analysis

🕗 Version & Regression Information

(see Playground) When trying to narrow generic types (unions), the control flow analysis is not aware of the narrowing. I also see that this PR: #43183 was supposed to address this.

Please keep and fill in the line that best applies:

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about type narrowing

⏯ Playground Link

Playground link with relevant code

💻 Code

const INITIAL_STATE = {
 1: 'test1',
 2: 'test2',
};
type State = typeof INITIAL_STATE;

const stateReducer = <Type extends keyof State>(
 state: State,
 action: { type: Type; value: string } | { type: 'clear'; value: number },
) => {
 if (action.type === 'clear') {
 // action.value is "string | number", but should be "number"
 return action.value;
 }

 return {
 ...state,
 [action.type]: action.value,
 };
};

stateReducer(INITIAL_STATE, { type: 'clear', value: 0 });

🙁 Actual behavior

action.value is "string | number"

🙂 Expected behavior

but should be "number"

Thanks in advance!

[whzx5byb]

{type: Type; value: string } |{type: 'clear'; value: number } is not a discriminated union so it may not be narrowed as the way you expected. To make it work, you have to distribute over the generic type Type.

const stateReducer = <Type extends keyof State>(
 state: State,
- action:{type: Type; value: string } |{type: 'clear'; value: number },
+ action: Type extends unknown ?{type: Type; value: string } |{type: 'clear'; value: number } : never,
) =>{

[andrewbranch]

It’s a fair question why type isn’t a discriminant property, though. It’s not that every constituent in the union needs a unit type, because this is discriminable:

- action:{type: Type; value: string } |{type: 'clear'; value: number },
+ action:{type: keyof State; value: string } |{type: 'clear'; value: number },

The fact that Type is a type parameter, though constrained to a union of literal types, prevents us from recognizing the property as a discriminant. The conditional type distributes, yes, but it also kind of un-genericizes by filling in the constraint, which lets us recognize the property as a discriminant. I don’t immediately see a great reason why we couldn’t say that a type parameter whose constraint is a literal type is a valid discriminant... but these things have a way of having unexpected rippling effects.

[fatcerberus]

It’s not that every constituent in the union needs a unit type

It's funny you say this because this was also my understanding for a long time. It's only due to past comments by @RyanCavanaugh that I found out the rule is the discriminant can either be a unit type or a union of unit types (thus why keyof State works as a discriminant). So I certainly wouldn't blame anyone who didn't realize that.

It's interesting that that conditional type trick works. I would expect it to just defer since it's distributive over a type parameter.

[wbt]

Here is another toy example demonstrating what I think is the same issue:

interface UpdateReport<B extends boolean = true> {
 newValue: string;
 oldValue: B extends true ? string : undefined;
}
export const processReport = function<B extends boolean>(
 report: UpdateReport<B>,
 hasOldValue: readonly [B],
) {
 if(hasOldValue[0]) {
 //Error TS(2345): Argument of type 'UpdateReport<B>'
 //is not assignable to parameter of type 'UpdateReport<true>'.
 //Type 'B' is not assignable to type 'true'.
 //Type 'boolean' is not assignable to type 'true'.
 //However, within this conditional check / type guard,
 //TS should be able to figure out that B is 'true'.
 let oldValue = getOldValueFromReport(report); //...
 }
}
const getOldValueFromReport = function(
 report: UpdateReport<true>
) {
 return report.oldValue;
};

Search terms: Type guard narrowing assignable to parameter of type 2345

[thetutlage]

Another one when using unions with generics.

type BcryptConfig = {
 rounds: number
 type: 'bcrypt'
}

type ArgonConfig = {
 variant: number
 type: 'argon'
}

function defineConfig<T extends { [key: string]: ArgonConfig | BcryptConfig }>(config: T): T {
 return config
}

defineConfig({
 passwords: {
 type: 'argon',
 variant: 1,
 rounds: 1,
 }
})

I expect the rounds: 1 parameter to be disallowed, since the property does not exists on the ArgonConfig.

[foxfirecodes]

any update on this? I find myself FREQUENTLY running into this issue, especially when dealing with things like events where there's multiple different types with different payloads. here's an example:

(ts playground)

type EventType = 'NEW_MESSAGE' | 'NEW_USER'

type AppEvent =
 | { type: 'NEW_MESSAGE'; message: string }
 | { type: 'NEW_USER'; user: string }

function fetchEvents<Type extends EventType>(
 eventType: Type
): Extract<AppEvent, { type: Type }> {
 if (eventType === 'NEW_MESSAGE') {
 // this errors, because typescript can't figure out that Type must be 'NEW_MESSAGE'
 return {
 type: 'NEW_MESSAGE',
 message: 'hello, world',
 }
 } else if (eventType === 'NEW_USER') {
 // this errors, because typescript can't figure out that Type must be 'NEW_USER'
 return {
 type: 'NEW_USER',
 user: 'rayzr',
 }
 } else {
 throw new Error(`Unknown event type: ${eventType}`)
 }
}

I do this kinda thing all the time when making abstractions to handle multiple types of input/output, and it's a pain to have to typecast the return types

[jcalz]

This looks like the same thing except the generic is constrained to something other than a union... but it should still probably be discriminable:

type Foo<T extends {}> =
 { a: undefined, b: string } | { a: T, b: number }

function foo<T extends {}>(f: Foo<T>) {
 if (f.a == null) {
 f.b // should be string, is actually string | number
 }
}

Playground link

[reiss-d]

I think this is a slightly different example of the control flow not narrowing the generic, only it's not a property access:

declare function takesString(value: string): void

const data = { a: 'foo', b: 1 }
type Data = typeof data

function getValue_generic<K extends keyof Data>(key: K) {
 if (key === 'a') {
 key // K extends "a" | "b"
 const value = data[key] //{a: string; b: number }[K]
 takesString(value) // Argument of type 'string | number' is not assignable to parameter of type 'string'.
 }
}

function getValue_non_generic(key: keyof Data) {
 if (key === 'a') {
 key // "a"
 const value = data[key] // string
 takesString(value) // ok
 }
}

Playground

[Lordfirespeed]

And another toy example (I believe):

const foo = {
 bar: ['hello', (value: 'hello' | 'bye') => {}],
 baz: [3, (value: 3 | 5) => {}],
} as const;

function doWithFoo<T extends keyof typeof foo>(key: T) {
 if (key === 'bar') {
 const [value, setValue] = foo[key];
 setValue('bye'); // error here
 }
}

https://stackblitz.com/edit/typescript-repro-eqknuz?file=src%2Fmain.ts

[gima]

"Type narrowing from control flow analysis doesn't backpropagate to another, type-dependent, conditional parameter's type".

The demonstration code below is identical* for both TypeScript and Flowtype.

1. 🔗 TypeScript Playground link
   Result: TypeScript's type checker doesn't manage to narrow the type.

2. 🔗 Flowtype Playground link
   Result: Flowtype's type checker manages to narrow the type correctly, as should be the case.
   *) (the code is otherwise identical, except for changing "String" to "string" and "Number" to "number").

The code in question:

type OneOfTwo = String | Number;
type ConditionalTybe<T, TRUETYBE, FALSETYBE> = T extends String ? TRUETYBE : FALSETYBE;

function funktion<T extends OneOfTwo> (arg1: T, arg2: ConditionalTybe<T, true, false> ) {
 if (typeof arg1 == "string") {
 if (arg2 === true) {}
 if (arg2 === false) {} // why is there no error here?
 }
}

funktion('str', true);
funktion('str', false); // correctly shows an error here.
funktion(1, true); // correctly shows an error here.
funktion(1, false);

If needed, I can provide a real and useful, and not terribly complex code example of this, where a correctly narrowed type would avoid a superfluous null check (to narrow the possibility of a null value out of a variable).