Inconsistent behavior between intersection literal type during inference about typescript HOT 10 CLOSED

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.

from typescript.

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.

from typescript.

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.

from typescript.

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…

from typescript.

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.

from typescript.

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.

from typescript.

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.

from typescript.

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.

from typescript.

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

from typescript.

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

from typescript.