Description
Suggestion
π 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 anextends
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. Awhere
clause would make it possible to introduce type aliases that don't appear in the generic parameter list. -
Partial inference for functions
See Allow skipping some generics when calling a function with multiple genericsΒ #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, awhere
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.