Add support for generic types on a index accessor

[ruochenjia]

🔍 Search Terms

index accessor
generic index accessor

✅ Viability Checklist

• 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, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

Allow type parameters to be used for an index accessor. This allows users to declare additional supporting methods within an interface that has a string index accessor with a value set to a non any or Function type, by using an overlay interface.

Example:

interface SuperRecord<Key extends keyof any, Value, Overlay = {}>{
	<E extends Key>[k: E]: E extends keyof Overlay ? Overlay[E]: Value;
};
interface K extends SuperRecord<string, string, { func1: () => void; }> {
	// Properties declared through the `SuperRecord` interface.
	// [k: string not "func1"]: string;
	// func1(): void;
}

let d: K = ...

d["anystringkey"] = "anystringvalue"; // properties not whitelisted in the overlay have the same behavior as a `Record<string, string>` interface type in this case.

d.func1(); // properties whitelisted by the overlay uses the value declared in the whitelist.

d.func1 = "A"; // error, as 'func1' exists in the overlay, so its corresponding type takes the priority.

📃 Motivating Example

This fixes #58256 and #17867, without using an intersection type. This would allow the type to be declared as an interface, which means it can be implemented by a class or extended by another interface without any errors caused by conflicting properties.

💻 Use Cases

1. What do you want to use this for?
   Various cases where an interface requires both an index accessor and other properties that could cause conflict in the type.
   Furthermore some types in lib.dom.d.ts can be improved, for example a string valued index accessor can be used for the Storage interface without affecting other supporting functions.

2. What shortcomings exist with current approaches?
   It might slow down the type checking process.

3. What workarounds are you using in the meantime?
   An intersection type like this:

type E = { [k: string]: string; } & { func1(): void };

which cannot be extended by an interface, or implemented by a class, due to property type conflicts.

[RyanCavanaugh]

This seems like just an exact duplicate of #17867.

You can already write

type SuperRecord<Key extends keyof any, Value, Overlay = {}> = {
    [E in Key]: E extends keyof Overlay ? Overlay[E]: Value;
};

to get the generic behavior on an index signature's output type, nothing new is needed.

[ruochenjia]

@RyanCavanaugh Logically the method you suggested should behave exactly the same as the one I mentioned above. However when I tested with the code below, only the key and value part works correctly, the overlay does not. Invoking a function on the overlay produces an error message:

This expression is not callable. Type 'String' has no call signatures.

The code I used:

type SuperRecord<Key extends keyof any, Value, Overlay = {}> = {
	[E in Key]: E extends keyof Overlay ? Overlay[E]: Value;
};
interface K extends SuperRecord<string, string, { func1(): void; }> {
}
let k: K = ...
k["str"] = "val"; // works fine
k.func1(); // error
k.toString(); // works fine

[RyanCavanaugh]

Right, you'd still need rest signatures. But K would be declared as this:

type O = { func1(): void; };
interface K extends SuperRecord<keyof O, string, O> {
  // TODO: Be able to uncomment.
  // [...rest: string]: string
}

[typescript-bot]

This issue has been marked as "Duplicate" and has seen no recent activity. It has been automatically closed for house-keeping purposes.