Support C# / Rust-style "where" syntax for generic parameters

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:

1. 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. A where clause lets you push the generic bounds and defaults outside the parameter list, improving its legibility.

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

3. 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:

1. You want users to specify it
2. You want it to be inferred

and there’s no syntax for distinguishing those. A where clause would let you do that.

[RyanCavanaugh]

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

interface Array<T> {
  // Proposing that "where" go at the end of the type parameter list
  includes<U where T extends U>(el: U): boolean
}

[danvk]

Also, if the where clauses didn’t influence inference at all, which I think would be desirable, then you could solve non-inferential type parameter (#14829) use cases:

declare function assertEqual<T, U where U extends T, T extends U>(actual: T, expected: U): boolean;
const g = { x: 3, y: 2 };
// Would correctly error
assertEqual(g, { x: 3 });

Or perhaps

declare function assertEqual<T, U where [U, T] extends [T, U]>(actual: T, expected: U): boolean;