Conditional type partially computed

[awerlogus]

Bug Report

🔎 Search Terms conditional type partially completely

🕗 Version & Regression Information 4.3.0-dev.20210406

💻 Code

// Expected: type A = number
// Got: type A = number[] extends (infer T)[] ? T : never
type A = Array<number> extends Array<any> ? Array<number> extends Array<infer T> ? T : never : never

🙁 Actual behavior

Type computed partially

🙂 Expected behavior

Type computed completely

[andrewbranch]

Changed between 3.8 and 3.9

[DanielRosenwasser]

I believe this must be a bug due to substitution types or something. For example, this works:

type A = Array<string> extends Array<any> ? Array<number> extends Array<infer T> ? T : never : never

It's unclear what to do in the general case - ideally here you'd get number out of T, but minimally it should not be a deferred conditional type.

[andrewbranch]

From conversation with Anders—why are we even making a substitution type that doesn’t include a type parameter? That seems fishy.

[weswigham]

We have for a long time. Any type on the LHS of a conditional extends gets substituted on - this is relied on in the wild quite a bit, as I've recently found out via some recent changes I've made.

[weswigham]

This is probably an issue where isGenericIndexType and isGenericObjectType - the things we use to see if we need to defer a conditional - don't return the result we think they should if we're looking at a substitution (which is really whatever it's a substitution to, rather than the instanstiable it looks like on first glance).

[VictorQueiroz]

I experience problems with the following in 4.2.4:

type Brand<T, U> = T & {__brand: U;};

type PrimaryKey<T> = Brand<T,'primaryKey'>;

type RemoveBrand<T> = T extends Brand<infer U, any> ? U : never;

type X = RemoveBrand<PrimaryKey<number>>;

In 4.2.4, X is number & {__brand: "primaryKey"}.

The exact same type works perfectly in 4.1.x. Not sure if this is a bug or I did something wrong. All I know is that I had this type working before 4.2 :(

[weswigham]

@VictorQueiroz that's a separate issue, and one we've gotten a lot recently, related to aliases. In short, we used to keep around a Brand<number, 'primaryKey'> alias, but now we make the more derived PrimaryKey<number> alias. Previously, we'd match the Brand aliases up, and match on their type arguments, getting you the result you wanted, whereas now, the alias don't match up, making us fall back to a structural inference, which yields a different (but technically still valid, since where you slice an intersection apart, if at all, when matching it is arbitrary) result. Essentially your example is just like #43161.