Indexable types don't accept type aliases

[kujon]

TypeScript Version: 2.4.2

Is there any reason for the following code failing to compile? As far as I'm aware, type aliases are resolved by TS quite early, so shouldn't the same be true in this case?

Code

type A = string;
type B = number;

type AIndexedNoAlias = {
    [index: string]: any;
};

type AIndexedAlias = {
    // An index signature parameter type must be 'string' or 'number'.
    [index: A]: any;
};

type BIndexedNoAlias = {
    [index: number]: any;
};

type BIndexedAlias = {
    // An index signature parameter type must be 'string' or 'number'.
    [index: B]: any;
};

Expected behavior:
The code above compiles

Actual behavior:
The code above fails to compile, with the following error: An index signature parameter type must be 'string' or 'number'.

[RyanCavanaugh]

Duplicate #7374 etc

[kujon]

I'm quite concerned with how the linked issue has been dealt with. There are a few examples (this being one of them) where TypeScript behaves in a silly way:

type A = {
  foo?: {
    bar: number;
  }
};

const demo = (value: A) => {
  const hasFoo = typeof value.foo !== undefined;

  if (hasFoo) {
    // Object possibly 'undefined'
    return value.foo.bar;
  }

  return 0;
}

switch(true) not supported, because of not being a common enough pattern, etc

I feel like they're brushed off, not due to disagreements about the language design, but because of the difficulty of implementation. As mentioned in the other issue, TS isn't a linter, but a language, so it's natural that the community is going to hold you to the higher standards than library authors.

As to this particular issue: type aliases are resolved very early on and from what I've noticed, everywhere apart from the original declaration, you'll see what's been aliased, rather than the alias itself. Following that logic, it'd be natural to support indexes on aliases which are either number or string. The same way TS doesn't restrict the use of string or number methods on them.

TypeScript is a brilliant addition to the JS ecosystem, and it would be a pity to miss the opportunity to make it even better.

[RyanCavanaugh]

I'm not sure how you got that impression. We could implement type alias key signatures rather easily, but as noted at #7374 (comment) , we felt that it would be an anti-feature as it would appear to imply different behavior than would be manifested by the type system. We regularly turn down features that we think would make the language worse rather than better; this should be uncontroversial as an approach to making software.

Regarding implementation difficulty as a factor for decision making -- I don't understand what the alternative would be. There are lots of suggestions that would require nearly complete rewrites of the checker to accomplish; not taking cost as a factor (i.e. we can do this 1 expensive thing or 10 moderate-difficulty things instead) seems counterproductive at best. We certainly haven't shied away from difficult features that deliver a lot of value - mapped types being a recent example.

[kujon]

Would you consider changing the error message to something more meaningful in this case? An index signature parameter type must be 'string' or 'number'. is misleading.

[RyanCavanaugh]

I think that'd be reasonable. Suggestions on a better wording?

[kujon]

3 different messages would be useful:

1. If an alias resolves to string or number: An index signature parameter type cannot be a type alias. Use '[index: ${aliasedType}]' instead.
2. If the parameter is a union of strings/numbers (aliased or not): An index signature parameter type cannot be a union type. Use '[K in ${unionType}]' instead.
3. For all other cases: An index signature parameter type must be 'string' or 'number'.

[mhegazy]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

[kujon]

@mhegazy - not sure why this was closed. Is there a plan to address the suggestions I've made, or is the proposal rejected?

[kujon]

Proposed fix: #20726

[mhegazy]

thanks @kujon!

[kujon]

Happy to help