Proposal: allow type arguments of generic being named

TypeScript Version: 2.7.0-dev.201xxxxx

Search Terms: named generic type parameters / arguments

Code

interface UserInfo { }
var usersMap: Map<sessionId: string, info: UserInfo>;

Expected behavior:
No error, Map<sessionId: string, info: UserInfo> should be equivalent to Map<string, UserInfo> .

Actual behavior:
Syntax error: Generic type 'Map<K, V>' requires 2 type argument(s).

Playground Link:
https://www.typescriptlang.org/play/#src=interface%20UserInfo%20%7B%20%7D%0D%0Avar%20usersMap%3A%20Map%3CsessionId%3A%20string%2C%20info%3A%20UserInfo%3E%3B

Rationale:
Without a name, it is not often immediately clear what a type argument really mean. Take Map<string, UserInfo> as an example, is the first argument a sessionId, a userId or something else? In contrast, Map<sessionId: string, info: UserInfo> or Map<sessionId: string, UserInfo> is very clear.

The name of a type argument doesn't affect the actual type, just like the name of argument of a function type.

When would the name sessionId ever get used by the compiler? It seems to me that this is better left to a comment.

It's the same with normal function calls:

let result = doStuff('foo', true, 3.14, 42); // what do all these mean?

The usual solutions are to either (a) place comments labeling each argument, or (b) pass an options object so callers have to specify key/value pairs, which is both extensible and self-documenting.

You could take both of these approaches with generics too. For example:

// Option A:
interface UserInfo { }
var usersMap: Map</*sessionId:*/ string, /*info:*/ UserInfo>;


// Option B:
interface UserInfo { }
type MyMap<T extends {sessionId: any, info: any}, U = T['sessionId'], V = T['info']> = Map<U, V>;

let usersMap: MyMap<{sessionId: string, info: UserInfo}>;

You can just do

type SessionId = string;

And then use that type.

This seems to introduce much more complexity than it produces in value.

This is super useful when you have a function that takes multiple generic arguments and you only want to assert one. This is a example of what the feature could be like: sandbox

This proposal has at least two very big advantages:

if you edit or change something it is less risky since you won't screw your types if you pass your params in a wrong position by mistake
it is way more readable when you have multiple parameters

It's the same with normal function calls:
let result = doStuff('foo', true, 3.14, 42); // what do all these mean?
The usual solutions are to either (a) place comments labeling each argument, or (b) pass an options object so callers have to specify key/value pairs, which is both extensible and self-documenting.

You could take both of these approaches with generics too. For example:
// Option A:
interface UserInfo { }
var usersMap: Map</*sessionId:*/ string, /*info:*/ UserInfo>;


// Option B:
interface UserInfo { }
type MyMap<T extends {sessionId: any, info: any}, U = T['sessionId'], V = T['info']> = Map<U, V>;

let usersMap: MyMap<{sessionId: string, info: UserInfo}>;

That's a proper JavaScript-like solution.

Navigation Menu

Repository navigation

Proposal: allow type arguments of generic being named #22631

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Proposal: allow type arguments of generic being named #22631

Description

Activity

danthedaniel commented on Mar 17, 2018

yortus commented on Mar 17, 2018

Airblader commented on Jun 9, 2018

RyanCavanaugh commented on Aug 23, 2018

iheb-draouil commented on Aug 21, 2022

AdrianDiazCode commented on Apr 18, 2023

samislam commented on Aug 4, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions