Repository: TypeScript
Issue: Enforce correct bounds on assignability when the target is a lookup type on a constrained type parameter
Labels: Suggestion,In Discussion

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker.

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ, especially the "Common Feature Requests" section: https://github.com/Microsoft/TypeScript/wiki/FAQ

-->

## Search Terms

interface extends generic argument

<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

## Suggestion

<!-- A summary of what you'd like to see added or changed -->

### Currently
There is a [difference](https://www.typescriptlang.org/play/?ssl=1&ssc=1&pln=11&pc=2#code/JYOwLgpgTgZghgYwgAgGIHt0AU5TgW2QG8BYAKGWQCFcAuZdAIwCsIEwBucgX3PJgCuIdsHQhkMTAB4AKsggAPSCAAmAZzSYcefAD4AFAEpi5SgjFqwyANb0ZAbQBENKI4C6yALzFuHZAHp-ZAB5AGkePjJBYTBRcUY4AC9ZeSUIVQ0mVnYDY1IKZHMQSxs7Lx8-QPkoKHQoHiA) between the validity of assignment to `k` in `foo` and `baz`. 

```ts
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

<!--
What do you want to use this for?
What shortcomings exist with current approaches?
-->
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

<!-- Show how this would be used and what the behavior would be -->

```ts
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:

```ts
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:

* :question:  This wouldn't be a breaking change in existing TypeScript/JavaScript code. 

:point_up: 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.

* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).