Enforce correct bounds on assignability when the target is a lookup type on a constrained type parameter

Search Terms

interface extends generic argument

Suggestion

Currently

There is a difference between the validity of assignment to k in foo and baz.

interface FooParam {
  Bar: object;
}

function foo<T extends FooParam>() {
  const k: T["Bar"] = {}; // OK
}

function baz<T extends object>() {
  const k: T = {}; // error
}

In baz, it is not possible to assign the empty object to k even though k is type T and T extends object. This, as I understand, is the correct behavior since an empty object cannot be guaranteed to be a subtype of T even though it is a subtype of object. (For instance, T could be number[] and then we'd have a problem).

In foo, on the other hand, it is possible to assign the empty object to k, even though it cannot be guaranteed that the empty object would be a subtype of T["Bar"]. For example, T could be something like { Bar: number[] }, and we would have essentially the same problem as in the case of baz.

Wanted

It should not be possible to assign to k in both cases.

Use Cases

I am currently using the above strategy of submitting an interface as generic argument as to reduce the number of places of arguments in the generics and make it more resistant to semantic changes in order.

The situation that I am facing is that of a functionality that needs many delegates that accepting a large set of different kinds of inputs and returning different kinds of outputs, but the exact set of inputs and outputs are kept generic and type-checked. Using placed generic arguments is error-prone and hard to read.

As it is currently, protection against the type not even being a subtype of the interface property type is already afforded (so, with the example above, assigning 2 to k which expects T["Bar"] is an error). This issue just requests that the full protection afforded by "standalone" type parameters are also afforded here.

Examples

function foo<T extends /*...*/,U  extends /*...*/,V /*... and so on */,W,X,Y,Z>(input: T,
   logic1: (input: T) => U,
   logic2: (input: U) => W,
   logic3: (input: W) => X,
   logic4: (input1: W, input2: X) => U,
   /* ... many more contextual callbacks */
) {
   /* ... */
}

This would then turn to something like so:

interface FooParams {
   T: /* ... whatever T extends */
   U: /* ... whatever U extends */,
   /* ... and so on, obviously with more sensible names */
}

function foo<Params extends FooParams>(input: Params["T"],
   logic1: (input: Params["T"]) => Params["U"],
   /* ... */
) {
   /* ... */
}

Checklist

My suggestion meets these guidelines:

• ❓ This wouldn't be a breaking change in existing TypeScript/JavaScript code.

☝️ JavaScript wouldn't break obviously. But since the TypeScript behavior would restrict what are currently valid typings, I'm honestly not sure because I don't know how idiomatic this usage is elsewhere and what/whether people currently actively expect to be the behavior.

• 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, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

Riproduci gli esempi di playground collegati che confrontano foo con baz, quindi esamina il percorso di type checking per i tipi di accesso indicizzato sui parametri di tipo vincolati. L'attività è completata quando le assegnazioni a T["Bar"] applicano gli stessi limiti delle assegnazioni a T, mentre le assegnazioni valide di sottotipi continuano a essere accettate.