Repository: TypeScript
Issue: Idea: 'rest' index signatures and the 'error' type
Labels: Suggestion,Needs Proposal

_[This idea is still in a relatively early stage of development, but I thought it may be of worth to someone or even for the TS team itself. Feel free to share your thoughts]_

Having literal types, or unions of them, in index signatures is an idea that was brought to discussion lately (see #5683, #7656 and more general discussion in #7660):

``` ts
interface Example {
    [letter: "a" | "b" | "c"]: number;
}
```

However the conventional semantics of index signatures would imply that the type checking here would be very weak, unless `noImplicitAny` is enabled:

``` ts
let x: Example;

x["a"] = 123; // OK
x["a"] = "ABCD"; // Error: type 'string' cannot be assigned to 'number'

x["d"] = 123; // No error with noImplicitAny disabled
x["d"] = "ABCD"; // No error with noImplicitAny disabled

x[123] = "ABCD"; // No error with noImplicitAny disabled
x[Symbol("ABCD")] = true; // No error with noImplicitAny disabled

let y = x["a"] // OK, 'y' gets type 'number'
let y = x["d"] // No error with noImplicitAny disabled, 'y' gets type 'any'
let y = x[123] // No error with noImplicitAny disabled, 'y' gets type 'any'
let y = x[Symbol("ABCD")] // No error with noImplicitAny disabled, 'y' gets type 'any'
```

What if it there was a way to specify the type of all the 'remaining' access keys to the interface with a special "rest" index signature (notated as `[key: ...any]: T`) that would set a particular type for everything other than that was specified in the interface?

``` ts
interface Example {
    [letter: "a" | "b" | "c"]: number;
    [otherKeys: ...any]: string;
}
```

This may also be useful to avoid unwanted type errors when `noImplicitAny` is **enabled**:

``` ts
interface Example {
    [letter: "a" | "b" | "c"]: number;
    [otherKeys: ...any]: any;
}
```

And what if it would be set to some sort of an 'error' type? I.e. a type that would not be assignable to or from anything? (perhaps except itself, still thinking about it..).

``` ts
interface Example {
    [letter: "a" | "b" | "c"]: number;
    [otherKeys: ...any]: <Error>;
}
```

With the `<Error>` type, any assignment to or from a key that is not `"a"`, `"b"` or `"c"` would yield an error, as it cannot be assigned to or from anything:

``` ts
let x: Example;

x["a"] = 123; // OK
x["a"] = "ABCD"; // Error: type 'string' is not assignable to 'number'

x["d"] = 123; // Error: type 'number' is not assignable to '<Error>'
x["d"] = "ABCD"; // Error: type 'string' is not assignable to '<Error>'

x[123] = "ABCD"; // Error: type 'string' is not assignable to '<Error>'
x[Symbol("ABCD")] = true; // Error: type 'boolean' is not assignable to '<Error>'

let y = x["a"] // OK, 'y' gets type 'number'
let y = x["d"] // Error: type '<Error>' cannot be assigned to anything
let y = x[123] // Error: type '<Error>' cannot be assigned to anything
let y = x[Symbol("ABCD")] // Error: type '<Error>' cannot be assigned to anything
```

Or even:

``` ts
x["d"] = <null> {}; // Error: type  'null' is not assignable to '<Error>'
x["d"] = <undefined> {}; // Error: type 'undefined' is not assignable to '<Error>'
x["d"] = <void> {}; // Error: type 'void' is not assignable to '<Error>'
x["d"] = <any> {}; // Error: type 'any' is not assignable to '<Error>'
```

**Open questions:**
1. What would be the implications in terms of indexing into an entity having this signature in its type?
2. What would be the implications in terms of assigning to an entity having this signature in its type?
3. What would be the implications in terms of assigning from an entity having this signature in its type?
4. Would adding `[key: any...]: <Error>` convert any interface to a "strict" interface? (i.e. one that cannot be assigned from a 'wider' type containing more properties). And if it would, would that be seen as desirable or useful?

_Edits: expanded and corrected examples to the actual behavior with `noImplicitAny` enabled._
_Edits: converted from 'bottom' to `<Error>` as I seemed to have used a less common interpretation of the 'bottom' type_
_Edits (13 May 2016): changed `[...]` to `[key: ...any]` for better consistency with the current syntax._