Inconsistent behavior between intersection literal type during inference

[unional]

🔎 Search Terms

literal intersection infer extract value

🕗 Version & Regression Information

Behavior changed since 5.1

⏯ Playground Link

https://www.typescriptlang.org/play?ts=5.5.0-dev.20240314#code/C4TwDgpgBASgjFAvFAdgVwLYCMICcoQAewEKAJgM6qY74D8Uwua0AXFAGYCGANhdAHoBjZhABQoSLABMSKAiIlyVBAyYso7bn0HD14ydBgBmOQuKlK1bHihrRmzr35QhIlhPBGALHPQ38ADIoAG8oLnYEAF8CC2VrWjt3NicdVz1RTykYAFY-GltgsIj5KBjFSyp-ROCASxQOWwBVJJb2FAgAN1s3YsiyrKMANjMoIvD+8rirBDqG5tbHDu78XonSqMHYAHZR8ZLo2KUrasKoesb8FoY21C6e4VnQ9eigA

💻 Code

type R1 = number extends number ? true : false // true
type R2 = 1 extends 1 ? true : false // true
type R3 = 1 extends number ? true : false // true
type R4 = number & { a: 1 } extends number ? true : false // true
type R5 = number & { a: 1 } extends number & infer U ? U : never // { a: 1 }
type R6 = 1 & { a: 1 } extends 1 & infer U ? U : never // { a: 1 }
type R7 = 1 & { a: 1 } extends number & infer U ? U : never // 1 & { a: 1 }

🙁 Actual behavior

see above

🙂 Expected behavior

R7 should returns { a: 1 } as 1 extends number.

Due to this and #54648 (comment),
currently it doesn't seem to have a way to write the IsNegative type (among others) anymore.

This is one of the problems caused by #54648. It would be great if that can be re-evaluated.

Additional information about the issue

tbh, IMO many types I wrote in type-plus would be best provided by TS itself to make the type system more predictable and enable us to write better types. One suggestion is to support typeof T for types, but that's a different topic.

[fatcerberus]

What would “typeof T for types” even mean? Given that typeof x specifically means “give me the type assigned to the thing called x in value-space” and you can’t console.log a type…

[unional]

What would “typeof T for types” even mean?

I'm still articulating that. Basically it returns string literal types like number, string, stringTemplateLiteral etc.

Then you can do typeof T extends 'numberLiteral' extends true ? ... : ...

It should be relatively easy to do inside TS as it has that info in the AST.

The problem of that approach is how to handle intersection types.

Another way is to provide type utils like IsStringTemplateLiteral<T> like what I have in type-plus.

There are some variants need to be handled such as distributive (IsString<number | string, { distributive: true }> -> boolean, IsString<number | string, { distributive: false }> -> false), and exact (IsString<'abc', { exact: true }> -> false), and special types (any | unknown | void | never) handling.

[Andarist]

type R6 = 1 & { a: 1 } extends 1 & infer U ? U : never // { a: 1 }
type R7 = 1 & { a: 1 } extends number & infer U ? U : never // 1 & { a: 1 }

inferFromMatchingTypes gets passed isTypeIdenticalTo here as matches so I bet that it's the reason why those behave differently.

[fatcerberus]

fwiw, technically the inference for R7 is not wrong - number & 1 & { a: 1 } still describes the type accurately. I don’t consider infer to be an exact science; it’s a bit like solving an equation in that there can be multiple valid solutions—just that in this case the compiler can only pick one.

[Andarist]

Ah, ye - totally. I certainly didn't want to imply that this is a bug - just why this is different today at the implementation level.

[unional]

understand. It depends on what is the definition of infer in terms of how does it consider and interact with sets.

The bottomline for me is whether if we have a not-too-hacky-way to build the types we want.

[RyanCavanaugh]

The general behavior of T & infer U is that it'll match exactly T & V to U = V, but otherwise for S & V, you'll get U = S & V. Both are correct bounds.

[unional]

Understand that this is not a defect. It's the same as @Andarist pointed out above.

Maybe the question is how it should behave when it comes to sets like number vs numeric literals, string is string literals, boolean vs true/false.

The question is twofold: consistency and application limitation.

At the moment, this infer behavior creates inconsistency compare to how conditional type works:

type P1 = number & { a: 1 } extends number ? true : false // true
type P2 = 1 & { a: 1 } extends number ? true : false // true
type P3 = number & { a: 1 } extends number & infer U ? U : never // { a: 1 }
type P4 = 1 & { a: 1 } extends number & infer U ? U : never // 1 & { a: 1 }

playground

Yes, we can explain that the implementation is using exact match, but that does not help user to reason the type. To be consistent, both extends and infer should perform exact match or act based on set.

Using 'a' & { a: 1 } extends 'a' & infer U ? U : never to extract { a: 1 } is not very practical.

If there is an alternative way to do that, or have a way to address the string template literal issue mentioned in the OP #54648, that would work.

[typescript-bot]

This issue has been marked as "Not a Defect" and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[unional]

Please consider re-open this. The inconsistency makes it not possible to write reusable generic types that work with intersection types.