Support C# / Rust-style "where" syntax for generic parameters
See original GitHub issueSuggestion
š Search Terms
- rust where
ā Viability Checklist
- This wouldnāt be a breaking change in existing TypeScript/JavaScript code: this would introduce new syntax that would currently be an error.
- This wouldnāt change the runtime behavior of existing JavaScript code: this would be a purely type-level construct
- This could be implemented without emitting different JS based on the types of the expressions: this would get erased at runtime
- This isnāt a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.): this would be a purely type-level feature
- This feature would agree with the rest of TypeScriptās Design Goals. Itās more inspired by the syntax in Rust than attempting to replicate it
ā Suggestion
Instead of writing:
function getProperty<T, K extends keyof T>(obj: T, key: K) {
return obj[key];
}
Youād also be allowed to write:
function getProperty<T, K>(obj: T, key: K)
where
T extends object,
K extends keyof T
{
return obj[key];
}
It might even be preferable to leave T
and K
off the generic parameters list (the bit inside <..>
), since the intent is most likely for them to be inferred based on obj
and key
, but weāll get to this later.
For a type alias, instead of:
type Pick<T extends object, K extends keyof Type> = {[k in K]: T[k]};
youād also be able to write:
type Pick<Type, Keys> = {[K in Keys]: Type[K]}
where
Type extends object,
Keys extends keyof Type;
This mirrors an identical syntax in Rust (see also Rust RFC 135) (update: and also C#, so I guess Anders knows about this!). It would solve three distinct problems:
-
Legibility When a function or type alias has many generic arguments, each with an
extends
clause and a default value, it can get difficult to pick out what the type parameters are, or even how many of them there are. Awhere
clause lets you push the generic bounds and defaults outside the parameter list, improving its legibility. -
Scoped type aliases Thereās no easy type-level equivalent of factoring out a variable to eliminate duplicated expressions like you would in JavaScript. A
where
clause would make it possible to introduce type aliases that donāt appear in the generic parameter list. -
Partial inference for functions See #10571. Itās not currently possible to specify one type parameter for a generic function explicitly but allow a second one to be inferred. By creating a place to put types thatās not the parameter list, a
where
clause would make this possible.
There are examples of all three of these in the next section.
š» Use Cases
Legibility
There are many examples of complicated generic parameter lists out there. Hereās one chosen at random from react-router:
export interface RouteChildrenProps<Params extends { [K in keyof Params]?: string } = {}, S = H.LocationState> {
history: H.History;
location: H.Location<S>;
match: match<Params> | null;
}
Itās clearer that there are two type parameters if you move the constraints and default values out of the way:
export interface RouteChildrenProps<Params, S> where
Params extends { [K in keyof Params]?: string } = {},
S = H.LocationState
{
history: H.History;
location: H.Location<S>;
match: match<Params> | null;
}
The existing workaround for this is to put each type parameter on its own line:
export interface RouteChildrenProps<
Params extends { [K in keyof Params]?: string } = {},
S = H.LocationState
> {
history: H.History;
location: H.Location<S>;
match: match<Params> | null;
}
Itās a judgment call which you prefer. I find the other two uses more compelling!
Scoped type aliases
With complicated generic types and functions, itās common to have repeated type expressions. Hereās a particularly egregious example (source):
import * as express from 'express';
/** Like T[K], but doesn't require K be assignable to keyof T */
export type SafeKey<T, K extends string> = T[K & keyof T];
export type ExtractRouteParams<Path extends string> = ...; // see https://twitter.com/danvdk/status/1301707026507198464
export class TypedRouter<API> {
// ...
get<
Path extends keyof API & string,
>(
route: Path,
handler: (
params: ExtractRouteParams<Path>,
request: express.Request<ExtractRouteParams<Path>, SafeKey<SafeKey<API[Path], 'get'>, 'response'>>,
response: express.Response<SafeKey<SafeKey<API[Path], 'get'>, 'response'>>,
) => Promise<SafeKey<SafeKey<API[Path], 'get'>, 'response'>>
) {
// ... implementation ...
}
}
wow thatās a lot of repetition! Hereās what it might look like with where
:
export class TypedRouter<API> {
// ...
get<Path extends keyof API & string>(
route: Path,
handler: (
params: Params,
request: express.Request<Params, Response>,
response: express.Response<Response>,
) => Promise<Response>
)
where
Params = ExtractRouteParams<Path>,
Spec = SafeKey<API[Path], 'get'>,
Response = SafeKey<Spec, 'response'>
{
// ... implementation ...
}
}
By introducing some local type aliases in the where
list, weāre able to dramatically reduce repetition and improve clarity. We should actually remove Path
from the type parameters list since the intention is for it to be inferred, but letās save that for the next example.
Existing workarounds include factoring out more helper types to reduce duplication, or introducing an extra generic parameter with a default value, e.g.:
class TypedRouter<API> {
// ...
get<
Path extends keyof API & string,
Spec extends SafeKey<API[Path], 'get'> = SafeKey<API[Path], 'get'>,
>(
route: Path,
handler: (
params: ExtractRouteParams<Path>,
request: express.Request<ExtractRouteParams<Path>, SafeKey<Spec, 'response'>>,
response: express.Response<SafeKey<Spec, 'response'>>,
) => Promise<SafeKey<Spec, 'response'>>
) {
// ... implementation ...
}
}
This still repeats the type expression twice (SafeKey<API[Path], 'get'>
), but since itās used three times, itās a win! This is kinda gross and creates confusion for users about whether Spec
is a meaningful generic parameter that theyād ever want to set (it isnāt).
Partial inference for functions
Sometimes you want to infer one generic parameter to a function and have the others be derived from that (#10571). For example (following this post):
declare function getUrl<
API, Path extends keyof API
>(
path: Path, params: ExtractRouteParams<Path>
): string;
This fails if you pass API
explicitly and try to let Path
be inferred:
getUrl<API>('/users/:userId', {userId: 'bob'});
// ~~~ Expected 2 type arguments, but got 1. (2558)
This problem could be solved by using where
to introduce a type parameter thatās not part of the generics list:
declare function getUrl<API>(path: Path, params: ExtractRouteParams<Path>): string
where Path extends keyof API;
This would allow Path
to be inferred from the path
parameter while still specifying API
explicitly and enforcing the extends keyof API
constraint. The only workarounds Iām aware of now involve introducing a class or currying the function to create a new binding site:
declare function getUrl<API>():
<Path extends keyof API>(
path: Path,
params: ExtractRouteParams<Path>
) => string;
A where
clause would help with the general problem that there are two reasons to put a type parameter in the generic parameters list for a function:
- You want users to specify it
- You want it to be inferred
and thereās no syntax for distinguishing those. A where
clause would let you do that.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:28
- Comments:12 (5 by maintainers)
I donāt love the syntactic positioning of this or the idea that it would be a place to introduce type parameters, but Iām compelled by this as an alternative approach to some other feature requests (specifically #14520 upper-bounded generics). You could imagine writing things like this
Or perhaps