Assume `type X = <T>() => Z<T>;` as having an optionnal generic type parameter to enable deducing the return type on generic methods

[denis-migdal]

🔍 Search Terms

"ReturnType","generic method"

✅ 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

Given the following types :

type X = <T>() => Z<T>;
// or
type X2<Y> = <T>(param: Y) => Z<T>;

I suggest we should be able to give a generic type parameter to the types :

type Xstr = X<string> ; // Xstr = <string>() => Z<string>
// or
type X2str<Y> = X2<Y><string> ; // X2str<Y> = <string>(param: Y) => Z<string>

📃 Motivating Example

When having classes with a generic method :

class Klass {
 method<T>(): Z<T> { ... }
}

We can get the method as : type X = Klass["method"] which would be type X = <T>() => Z<T>.

However, to my knowledge, there are currently no ways to get the return type like :

type Return<T> = ReturnType<Klass["method"]<T>>; // expected : Return<T> = Z<T>
// currently gives an error : "; expected"

We can only do :

type Return = ReturnType<Klass["method"]>; // Return = Z<unknown>

However, it is possible to do :

type X = Klass["method"]>;

let tmp: X = {} as any; // h4ck for the demonstration
type Return<T> = ReturnType<typeof tmp<T>>; // Return<T> = Z<T>

💻 Use Cases

1. What do you want to use this for?

Get the returned type of a generic method.

2. What shortcomings exist with current approaches?

There are no current approaches to my knowledge.

3. What workarounds are you using in the meantime?

Couldn't find any. If you find some, I'm interested.

[denis-migdal]

It seems there is a workaround if we know the class :

type Z<T> = {val: T};

class Test {
	build<T>(): Z<T> {
		throw new Error();
	}
}

function inferHelper<Klass extends Test, T>() {

	type test = Klass["build"];
	let a:test = {} as any;
	return a<T>
}

type Return = ReturnType<ReturnType<typeof inferHelper<Test, number>>>; // Return = {val: number}

However, if we don't know the class :

abstract class Builder {
 abstract build<T>(): any;
}

class Test extends Builder { ... }

function inferHelper<Klass extends Builder, T>() { ... }

type Ret<Klass extends Builder> = ReturnType<ReturnType<typeof inferHelper<Klass, number>>>;
type Return = Ret<Test> // Return = any instead of Return = {val: number}

[jcalz]

I'd interpret this as a request for "instantiation types" as opposed to instantiation expressions as implemented in #47607 (which cannot directly be used to get this functionality, as you note above, and as mentioned in #47607 (comment)). Also cross-linking #53410

[denis-migdal]

I'd interpret this as a request for "instantiation types" as opposed to instantiation expressions as implemented in #47607 (which cannot directly be used to get this functionality, as you note above, and as mentioned in #47607 (comment)). Also cross-linking #53410

Thanks for your answer.

I read in #47607 (comment)) that the syntax T<X> is a bad idea as it would be ambiguous :

At least, if we did, it wouldn't be immediately obvious whether T means "apply type arguments to generic type T" or "apply type arguments to generic signatures in type T (without instantiating T itself)".

I would disagree with that, but if it is an issue, then, why not a AsGeneric utility function ?

type Foo = <T>() => T is the concrete, non-generic type of a generic function.

Solution:

type GFoo<U> = AsGeneric<Foo, U>; // GFoo<U> = <U>() => U
type SFoo = GFoo<string> // SFoo = <string>() => string
type SFoo = AsGeneric<Foo, string>; // SFoo = <string>() => string

[fatcerberus]

I would disagree with that [that the syntax is ambiguous]

That isn't just academic wheel-spinning, for what it's worth. It's a real issue, e.g. what would TS do here?

type Foo<T = string> = <U>(x: T) => U;
type Bar = Foo<number>;

Does number apply to T or U here? Both interpretations are valid, because you can instantiate Foo without explicitly providing T. Therefore the above could be interpreted two ways:

1. T defaults to string and U = number. Bar resolves to concrete function type (x: string) => number.
2. T = number. Bar resolves to generic function type <U>(x: number) => U.

[denis-migdal]

Does number apply to T or U here? Both interpretations are valid, because you can instantiate Foo without explicitly providing T. Therefore the above could be interpreted two ways:

1. `T` defaults to `string` and `U = number`. `Bar` resolves to concrete function type `(x: string) => number`.

2. `T = number`. `Bar` resolves to generic function type `<U>(x: number) => U`.

Knowing that we can write Foo<>, then why not considering :

type Bar = Foo<number> // = <U>(x: number) => U;
type Bar = Foo<><number> // = number)(x: string) => number

[denis-migdal]

However, if we don't know the class :

I found it strange so I made some tests :

{
	class BaseClass<V> {
		protected fake(): V { throw new Error("") }
	}

	class Klass<V> extends BaseClass<V>{}

	type Constructor<P extends BaseClass<number>> = new () => P;
	type inferTest<T> = T extends Constructor<infer P> ? P :never;

	type U = inferTest<Constructor<Klass<number>>> // U = Klass<number>
}

But when we add a generic type parameter :

{
	class BaseClass<V> {
		protected fake(): V { throw new Error("") }
	}

	class Klass<V> extends BaseClass<V>{}

	type Constructor<V, P extends BaseClass<V>> = new () => P;
	type inferTest<V, T> = T extends Constructor<V, infer P> ? P :never;

	type U = inferTest<number, Constructor<number, Klass<number>>> // U = BaseClass<number>
}

Is this a bug or an intended behavior ?

[denis-migdal]

I tried to do a minimal reproducible example, and I think I found the issue.

Functions return type are computed only once, when declaring the function, however the return type isn't precise enough.
For example :

{
	class Base {
		get self(): Base { return this }
	}
	class Child extends Base {
		override get self(): Child { return this }
	}

	function convert<T extends Base>(X: T) {
		return X.self;
	}

	const value = convert( new Child() );
	// expected: typeof value = Child.
	// got: typeof value = Base.
}

convert return type is : Base when it should be : T["self"] (which extends Base).

However, this would cause issue when the method/attribute has a generic, requiring to use AsGeneric<T["self"], U>.
Maybe a condensed notation could be something like : T["self"<U>].

[denis-migdal]

Another solution would be to make use of the satisfies keyword on types :

type X<T> = <T>() => {val: T};
type Y = <T>() => {val: T, child: true}
type Z = Y satisfies X<string> // Z = <string>() => {val: string, child: true}

[RyanCavanaugh]

Duplicate #50481 and others. The proposed solution isn't really tractable IMO; it's very problematic for the same syntax to do two completely different things.

[denis-migdal]

Duplicate #50481 and others. The proposed solution isn't really tractable IMO; it's very problematic for the same syntax to do two completely different things.

What about the other suggestion : type T<U> = AsGeneric<Foo, U> ?

I don't know what syntax would be the best, but we do need such feature as there is currently no workaround for it.

[typescript-bot]

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