Why does { foo: T } not satisfy { [key:string]: T }?

[MrHen]

Various libraries I use want to see dictionary "loops" that take some number of key/value pairs and operate on them. E.g.:

async.auto<any>({
   'foo': (cb) => getFoo(cb),
   'bar': ['foo', (cb, results) => getBar(results.foo)]
}, (err, results) => { ... });

The typings file for async likes to define helper dictionary types like this:

interface Dictionary<T> { [key: string]: T; }

Periodically, I need to create these key/value pairs conditionally and on the fly but the compiler yells at me if I try to send it in without explicitly typing my temporary object:

var block = {
    'foo': (cb) => getFoo(cb),
    'bar': ['foo', (cb, results) => getBar(results.foo)
}

if (flag) {
    block.foo = getOtherFoo(cb);
}

async.auto<any>(block, (err, results) => { ... });

block now technically satisfies the { [key: string]: T; } because it is an object with two keys, both strings. TypeScript will still yell at me for it, though, unless I explicit add a similar dictionary type to block. I, therefore, find myself putting this dictionary type all over the place just to satisfy what seems to be an arbitrary distinction between what is or is not a key:string.

This comes up enough that I find the type bloat irritating and it also makes it a requirement to only access block.foo as block['foo'].

[MrHen]

After browsing the issues a bit deeper, this may be the same thing as #5683.

[sandersn]

What is the error you get? It looks to me that you'll get a different type inferred for the values of block -- the first is a function and the second is a tuple. I would expect Typescript to complain that it can't infer a type for T.

[ahejlsberg]

@MrHen Can you post a repro that shows the exact issue?

[MrHen]

@sandersn, @ahejlsberg Here is a Playground link. The error I'm used to seeing is:

Argument of type '{ 'foo': (cb: any) => void; 'bar': (cb: any) => void; }' is not assignable to parameter of type 'Dictionary<{}>'.
Index signature is missing in type '{ 'foo': (cb: any) => void; 'bar': (cb: any) => void; }'.

Turns out an important difference is whether I explicitly use <any> on the function call which I had accidentally included above:

async.auto<any>(block, (err, results) => { ... }); // works
async.auto(block, (err, results) => { ... }); // error

I suppose I can use the <any> workaround for now.

[joeskeen]

Here is another (simplified) example of what I ran into when using Angular's $http (Playground link):

interface HttpHeaders {
    [key: string]: string
}

interface HttpService {
    <T>(path: string, method: string, headers: HttpHeaders): PromiseLike<T>;
}

let httpService: HttpService;
//this works:
httpService('', '', {
    'Content-Type': 'application/x-www-form-urlencoded'
});
//this does not:
const headers = {
    'Content-Type': 'application/x-www-form-urlencoded'
};
httpService('', '', headers); 

It results in the same error:

Argument of type '{ 'Content-Type': string; }' is not assignable to parameter of type 'HttpHeaders'. Index signature is missing in type '{ 'Content-Type': string; }'.

[RyanCavanaugh]

http://stackoverflow.com/questions/22077023/why-cant-i-indirectly-return-an-object-literal-to-satisfy-an-index-signature-re

[MrHen]

@RyanCavanaugh That's a good explanation for what happens but it's still kind of irritating because of how many libraries take dictionary-esque parameters.

From the SO example:

function c(): StringMap {
   var result = { a: "1" };
   return result; // Error - result lacks index signature, why?
}

It is really annoying to add explicit index signatures to variables like result and many of the typings files I consume don't bother to export their types. This is reasonable:

function c(): StringMap {
   var result: StringMap = { a: "1" };
   return result;
}

But this gets old:

function c(): StringMap {
   var result: {[key: string]: string} = { a: "1" };
   return result;
}

Especially for libraries like async where the types can get weird.

[RyanCavanaugh]

I don't know what the answer is, but it's clear this is becoming really annoying as definition file authors provide increasingly precise type definitions (I think two years ago, we would have seen someone write :any instead of : { [headerName: string]: string }).

[RyanCavanaugh]

Proposing the following change: If we are trying to assign S to T and T has a string index signature, S does not need to have a string index signature if all its known properties are assignable to the index signature type.

Pre-buttal: What about aliasing? Well, we already have this hole, which is basically equivalent:

let a = { x: 4, y: 'oops' };
let b: { x: number } = a;
let c: { x: number; y?: number } = b;
c.y.toFixed(); // Runtime error

Informally, we can choose to think about the indexer [k: string] T as being equivalent to "An optional property of type T for every possible name".

master...RyanCavanaugh:inferStringIndexers#diff-8b210ad15fe8058f8cadce2a5a0c71ccR1

[ahejlsberg]

@RyanCavanaugh What about cases like this?

let x: {};  // x can be any object
x = { a: 10, b: true };
let stringMap: { [x: number]: string } = x;  

Effectively the {} type would completely defeat index signature checking because it has no known properties.