user friendly infer

[AcsedyFN]

🔍 Search Terms

infer too complicated, infer logic mismatch, infer improvement

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

In an expression such as type Something<T> = T extends Promise<infer U> ? U : never; the occurence of "infer U" will receive the type within the pattern it resides and syntactically suggests that U is the type that is received within that layer (thinking about layer depth as in PromiseIsLayer1<infer UIsLayer2OrTheInnermostLayer>). However, within the conditional it becomes clear that U now refers to the pattern as a whole, checking not only the received type within the (in this case) generic, but also the structure surrounding it.

Therefore I suggest the infer keyword to be used differently and a new keyword to be added (any solution that is a readable and self explanatory syntax would be sufficient)

📃 Motivating Example

type Something<T> = T extends pattern Promise<infer> U ? U : never;
The keyword "pattern" would ensure the intuitive understanding of the following to be taken as a whole and assign it to the temporary type variable U, making it explicitly a type consisting of that pattern. The infer keyword only holds the type information and places it in the resolved form of U, in that case we could assume Something<Promise<string>> being Something<U>. I see no reason not to omit the variable next to infer, which could receive a variable to store the type information in under the hood.

💻 Use Cases

1. What do you want to use this for?
   A better developer experience, that is more intuitive and fits the logic the underlying implementation follows.

2. What shortcomings exist with current approaches?
   It is not intuitive and exhibits logical flaws that have to be overcome to gain the understanding that could be easily there.

3. What workarounds are you using in the meantime?
   Understanding the concept using more time than necessary. Grasping it isn't the problem, it is the average amount of time spent on it, that holds developers back.

[Renegade334]

It's kinda difficult to parse the explanation, but it sounds like you're describing infer ... extends?

https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-7.html#extends-constraints-on-infer-type-variables

[MartinJohns]

I don't see the benefit in having an alternative syntax for an existing feature, that is even more limited in functionality. That will lead to more confusion.

[AcsedyFN]

The feature exists, but it is not as accessible as it could be due to the ambiguity in meaning. The keyword "infer" paired with the temporary type variable suggests, that it only holds the type received on the inner part. After the ternary operator the same temporary type variable is used to refer to the whole pattern. Would you tell me how the alternative syntax is limiting functionality? I would like to adapt it to any case I haven't thought about.

[MartinJohns]

The keyword "infer" paired with the temporary type variable suggests, that it only holds the type received on the inner part. After the ternary operator the same temporary type variable is used to refer to the whole pattern.

I don't understand what you mean by this. Can you elaborate? When you have the conditional type Promise<infer U> and you pass in a Promise<string>, then U will only refer to the "inner part", aka string. U will not refer to the "whole pattern".

Would you tell me how the alternative syntax is limiting functionality?

You can infer multiple types, e.g. T extends Example<infer T1, infer T2> ? [T1, T2] : never

[olivermrose]

The way I understand it, they mean that Foo<infer U> on something like Foo<Bar<Baz<string>>> infers Bar<Baz<string>> instead of just string, which makes complete sense considering you can do Foo<Bar<Baz<infer U>>> if you want string.

[AcsedyFN]

You can infer multiple types, e.g. T extends Example<infer T1, infer T2> ? [T1, T2] : never

That's a very good point. In this operation the extraction of the types only occurs if the pattern matches the wrapping object Example<>, but the extracted types are still within the temporary type variables, changing my solution to omitting the need of a variable holding the pattern and instead only retaining the need for the "pattern" keyword to understand the impossibility of type extraction without the matching pattern. However, now that I think of it, pattern matching is implied by the ternary operation's left side already, but my limited understanding had me not thinking that the extends keyword already checks the incoming type for assignability to the following pattern.

Thanks for clearing that up.

[MartinJohns]

the extracted types are still within the temporary type variables

I don't get it. In your example you specify such a type named U as well. All you do is move this identifier away from the infer keyword and introduce a new keyword.

[AcsedyFN]

the extracted types are still within the temporary type variables

I don't get it. In your example you specify such a type named U as well. All you do is move this identifier away from the infer keyword and introduce a new keyword.

That's why after you've given the example I now think it wouldn't make sense. The information about the pattern matching was already contained in the extends keyword paired with the ternary operator that checks for assignability. In here the whole pattern gets checked, including everything that isn't inferred. When the pattern matches, U is retrieved from that pattern as the type.

[jcalz]

I still don't understand the syntax of the suggestion but it sounds like even the OP doesn't want/need this anymore? If so, maybe they could close the issue?

[RyanCavanaugh]

Either I'm misunderstanding what this is asking for (please have more clear examples), or it already exists as

type Something<T> = T extends infer U extends Promise<any> ? U : never;

// M: Promise<string>
type M = Something<Promise<string>>;
// N: never
type N = Something<string>;

[typescript-bot]

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