Repository navigation
Inconsistent behavior between intersection literal type during inference #57776
Description
🔎 Search Terms
literal intersection infer extract value
🕗 Version & Regression Information
Behavior changed since 5.1
⏯ Playground Link
💻 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.
Activity
[-]Inconsistent behavior between literal and infer[/-][+]Inconsistent behavior between intersection literal type in inference[/+][-]Inconsistent behavior between intersection literal type in inference[/-][+]Inconsistent behavior between intersection literal type during inference[/+]fatcerberus commentedon Mar 14, 2024
What would “
typeof Tfor types” even mean? Given thattypeof xspecifically means “give me the type assigned to the thing calledxin value-space” and you can’tconsole.loga type…unional commentedon Mar 14, 2024
I'm still articulating that. Basically it returns string literal types like
number,string,stringTemplateLiteraletc.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 intype-plus.There are some variants need to be handled such as
distributive(IsString<number | string, { distributive: true }> -> boolean,IsString<number | string, { distributive: false }> -> false), andexact(IsString<'abc', { exact: true }> -> false), and special types (any|unknown|void|never) handling.Andarist commentedon Mar 14, 2024
inferFromMatchingTypesgets passedisTypeIdenticalTohere asmatchesso I bet that it's the reason why those behave differently.fatcerberus commentedon Mar 14, 2024
fwiw, technically the inference for
R7is not wrong -number & 1 & { a: 1 }still describes the type accurately. I don’t considerinferto 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 commentedon Mar 14, 2024
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 commentedon Mar 15, 2024
understand. It depends on what is the definition of
inferin 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 commentedon Mar 15, 2024
The general behavior of
T & infer Uis that it'll match exactlyT & VtoU = V, but otherwise forS & V, you'll getU = S & V. Both are correct bounds.unional commentedon Mar 15, 2024
Understand that this is not a defect. It's the same as Mateusz Burzyński (@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
inferbehavior creates inconsistency compare to how conditional type works: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
extendsandinfershould perform exact match or act based on set.Using
'a' & { a: 1 } extends 'a' & infer U ? U : neverto 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 commentedon Mar 20, 2024
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 commentedon Mar 23, 2024
Please consider re-open this. The inconsistency makes it not possible to write reusable generic types that work with intersection types.