Type assignable to index access of constraint of type parameter is incorrectly assignable to the index access itself

[paulnelson2]

Bug Report

🔎 Search Terms

generic subtype, generic constraint

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about generic subtypes

⏯ Playground Link

(strict settings)
Playground link with relevant code

💻 Code

interface ContainerBase {
  success: boolean;
  item: {
    itemId: string;
  };
}

interface MyContainer {
  success: boolean;
  item: {
    itemId: string;
    thing: {
      color: string;
      size: number;
    };
  }
}

function getItemAndCheck<ContainerT extends ContainerBase>(container: ContainerT): ContainerT["item"] {
  if (!container.success) {
    throw new Error(`container success fail`);
  }
  //return container.item; // good code
  return {itemId: "id"}; // bad code, but tsc raises no error.
  // The error could be (for example): '{itemId: "id"}' is assignable to the constraint of type 'ContainerT["item"]',
  // but 'ContainerT["item"]' could be instantiated with a different subtype of constraint '{itemId: "id"}'
  // (like existing errors about generic subtypes)
}

const item = getItemAndCheck(fetchMyContainer());
console.log(item.thing.color); // throws an error at runtime but tsc raised no error earlier
                               // the caller thinks 'item' is the property of the specific subtype MyContainer but inside
                               // getItemAndCheck() you can return any subtype not just that one.

function fetchMyContainer(): MyContainer {
  // example
  return {
    success: true,
    item: {
      thing: {
        color: "green",
        size: 42,
      },
      itemId: "id",
    }
  }
}

🙁 Actual behavior

No error but there should have been.

🙂 Expected behavior

An error on the return statement of getItemAndCheck().

Use case

A rest api which returns data with very similar top level structure, but with differing nested properties, and wanting to write generic handlers for all responses.

Workaround

One could make the properties of the generic themselves generic type parameters as well, but this becomes more difficult the more complex the types are or if you want to manipulate several different properties in a generic way instead of one.

[DetachHead]

here is a more minimal example:

//no error
const impostor = <T extends [string|number]>(): T[0] => 'i am string'

const a: number = impostor<[number]>() // actually is string

a.toExponential() //runtime error

[gabritto]

So, I think this is a known design limitation in the way we check assignability in our type system.
To clarify: the reason there's no error on the original example is that when we check if the type of the return { itemId: "id" } is assignable to the annotated return type ContainerT["item"], we check if { itemId: "id" } is assignable to the constraint of ContainerT["item"], which is ContainerBase["item"] = { itemId: string }, so we conclude it is assignable.
The general rule is this: "A type S is related to a type T[K] if S is related to C, where C is the base constraint of T[K] for writing" (implemented here: https://github.dev/microsoft/TypeScript/blob/3fd8a6e44341f14681aa9d303dc380020ccb2147/src/compiler/checker.ts#L19368).
The rule is knowingly unsound, and it is unfortunate that we don't error on cases like the above, but the rule is useful in ways explained in this comment.

As to workarounds, I think you're right: this assignability rule only applies for an indexed access T[K] if the constraints of T and K are not themselves generic, so to evade this rule, you'd have to make sure either the constraint of K is generic, or the constraint of T is generic. The result would probably be something less ergonomic than the original code 🙁.

We have made this assignability rule more strict over time, like here and here, but for this specific case pointed out here, I don't see how we could make the rule not applicable, since the index type in the examples is concrete ("item" and 0 in the example programs, respectively), which is exactly the case pointed out that we want to support (equivalent to e.g. this["xxx"]).

[craigphicks]

I don't think this is a limitation, but rather a correct feature.
It is similar the way that JS getters are intended allow the user to massage values - although getters are not the issue here, the need is similar. Consider this:

function getItemAndCheck2<ContainerT extends ContainerBase>(container: ContainerT): ContainerT["item"] {
  ...
  return { itemId: container.item.itemId.toLocaleUpperCase() }; // an error here would be user unfriendly
}

It is a good thing that return value is not constrained in the way the OP suggests.

[DetachHead]

@craigphicks i don't get what would make an error there any less user friendly than in the original getItemAndCheck function from the OP. do you mean if container.item.itemId.toLocaleUpperCase() was an error? because i don't see why it would be, since ContainerT["item"] will always have itemId

[craigphicks]

@Detach head - A more slim example

function getItemId<ContainerT extends ContainerBase>(container: ContainerT): ContainerT["item"]["ItemId"] {
  return container.item.itemId.toLocaleUpperCase(); // an error here would be user unfriendly
}

I am saying functional access to members is a common way to allow transformations of the returned member. It's a common software pattern. A common software pattern shouldn't trigger an error.
I understand your counterargument that string could have been used instead of ContainerT["item"]["ItemId"] , and agree to disagree whether such usage should error.

If your example is rewritten as:

function impostor1<T extends [string|number]>(...args:T){
    return 'i am string';
} 
const ng: number = impostor1(1);
// const ng: number
// Type 'string' is not assignable to type 'number'.(2322)

an error is produced. I do agree that

const impostor = <T extends [string|number]>(): T[0] => 'i am string'

should produce an error for the same reason that imposter1 does.