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

🔍 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

What do you want to use this for?

Get the returned type of a generic method.

What shortcomings exist with current approaches?

There are no current approaches to my knowledge.

What workarounds are you using in the meantime?

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

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}

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

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

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:

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

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

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 ?

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>].

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}

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.

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.

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

Navigation Menu

Repository navigation

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

🔍 Search Terms

✅ Viability Checklist

⭐ Suggestion

📃 Motivating Example

💻 Use Cases

Solution:

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

🔍 Search Terms

✅ Viability Checklist

⭐ Suggestion

📃 Motivating Example

💻 Use Cases

Activity

denis-migdal commented on Jan 20, 2024

jcalz commented on Jan 20, 2024

denis-migdal commented on Jan 20, 2024

Solution:

fatcerberus commented on Jan 20, 2024

denis-migdal commented on Jan 20, 2024

denis-migdal commented on Jan 20, 2024

denis-migdal commented on Jan 21, 2024

denis-migdal commented on Jan 22, 2024

RyanCavanaugh commented on Jan 22, 2024

denis-migdal commented on Jan 22, 2024

typescript-bot commented on Jan 25, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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