typeof should be able to apply directly to function calls

[Autumn-one]

Suggestion

🔍 Search Terms

typeof function return

✅ Viability Checklist

My suggestion meets these guidelines:

• [ x ] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [ x ] This wouldn't change the runtime behavior of existing JavaScript code
• [ x ] This could be implemented without emitting different JS based on the types of the expressions
• [ x ] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• [ x ] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

The following operations should be supported

// Let's say I already have a function
declare function fn(): string;
// This operation fits well with intuition and existing usage，But it is not yet supported
type ret = typeof fn();

The following is written in the manner now supported

const a1 = fn();
type ret = typeof a1;

It is obvious that the style of writing now supported is redundant，if I use analogy, I think it is like a programming language declaration and initialization. If a programming language supports declaration and initialization separately, then the declaration and initialization written together should also be supported.

[MartinJohns]

ReturnType<typeof fn>

[Autumn-one]

ReturnType<typeof fn>

There is a fundamental difference between this and my suggestion. One is to simply obtain the return value type of the function, and the other includes a complete type inference process for the function. I have raised a question about the specific situation in stack overflow：https://stackoverflow.com/questions/76668843/why-cant-you-get-the-return-type-of-a-function-call-directly-through-typeof-in

[MartinJohns]

the other includes a complete type inference process for the function

The types must be known at compile time, so it doesn't matter if you provide the type as an argument, or a type argument. So you can just do:

declare const fn: <T>(arg: T) => T extends string ? number : boolean;

type a1 = ReturnType<typeof fn<"abc">>; // number
type a2 = ReturnType<typeof fn<123>>; // boolean

[Autumn-one]

the other includes a complete type inference process for the function

The types must be known at compile time, so it doesn't matter if you provide the type as an argument, or a type argument. So you can just do:

declare const fn: <T>(arg: T) => T extends string ? number : boolean;

type a1 = ReturnType<typeof fn<"abc">>; // number
type a2 = ReturnType<typeof fn<123>>; // boolean

'fn(123)' is to test the whole type inference process of the function fn, and 'fn<123>' is just to get a specific type, I don't know if I can express myself by saying that?
Of course, the ultimate purpose of this issue is to hope that the official can support such as' type ret = typeof fn(123) 'writing.

[jcalz]

I’m interpreting the ask here as “if I can write const x = expr; type X = typeof x; I should be allowed to write type X = typeof expr;”

So this is a duplicate of #6606. That issue is closed as too complex, and there are other open issues for parts of it unsatisfied by conditional types (such as #40179 for function calls specifically) but nothing for the whole of #6606.

I’m not suggesting that this issue be closed or that it stay open; just providing info on related issues to (hopefully) help with triage.

[Autumn-one]

I’m interpreting the ask here as “if I can write const x = _expr_; type X = typeof x; I should be allowed to write type X = typeof _expr_;”

So this is a duplicate of #6606. That issue is closed as too complex, and there are other open issues for parts of it unsatisfied by conditional types (such as #40179 for function calls specifically) but nothing for the whole of #6606.

I’m not suggesting that this issue be closed or that it stay open; just providing info on related issues to (hopefully) help with triage.

Yes, this expression is very concise and effective. I think the current typeof is incomplete, because the proposed usage is very consistent with most people's intuition and long-term programming habits. This feature has sufficient weight, so I hope to strive for official attention to this function. This is not a feature that should be rejected on the grounds that it is too difficult to implement.

[fatcerberus]

This is not a feature that should be rejected on the grounds that it is too difficult to implement.

Regardless, this #6606 (comment) feels like a pretty big hurdle to overcome (note: Ryan is the TS project lead). Apparently the thinking isn't so much "this would be too difficult to implement" but rather "this would make the language itself too complicated".

If you ultimately only care about function calls, #40179 is still open and Awaiting More Feedback, however, so there's hope on that front at least.

[typescript-bot]

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