Improve error message for union indexing

[nmain]

Search Terms

union, index

Suggestion

When a type union is used to index into a type with no index signature, if the property names match up correctly the access is allowed and Typescript does the "right thing" anyway. If the property names don't match up, and there's no index signature, an error is given, but it might not be the most helpful error.

Use Cases

I have a type that's a union of string literals, and I want to create some mapping for them. But if I forget a single property name, the error doesn't help me find what was missing

Examples

// noImplicitAny

type Froot = "orange" | "apple" | "banannanana";

const frootsToNames = {
    orange: "Orangey",
    apple: "Appley",
    banannanana: "Kiwiey"
};

const frootsToNamesBroken = {
    orange: "Orangey",
    apple: "Appley",
    bananana: "Kiwiey"
};

declare var f: Froot;

// works fine
frootsToNames[f];

// reports error:
// Element implicitly has an 'any' type because type
//     '{ orange: string; apple: string; bananana: string; }' has no index signature
// could report better error:
// Element implicitly has an 'any' type because possible key
//     'banannanana' from type Froot is missing on type '{ orange: string; apple: string; bananana: string; }', 
//     and no index signature
frootsToNamesBroken[f];

Related

#14951

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• 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.

[DanielRosenwasser]

If the indexing type is or is a union containing a literal type, we can provide a better error message.

[dragomirtitian]

@DanielRosenwasser Can I work on this one?

[DanielRosenwasser]

Go for it, but make sure it makes sense for a single-element string, and a union of string literals, and a union of string literals + a non-indexable member.

[dragomirtitian]

@DanielRosenwasser It's probably too late for this to make it into 3.5, but I would really appreciate it if you could review it the PR when you get a chance. I want to make any required changes until 3.5 is released so this is ready to be merged when the dev cycle for 3.6 starts.

Thank you.

[DanielRosenwasser]

Thanks @dragomirtitian!