Index constraint does not constrain

[dsherret]

It seems the index constraint doesn't seem to constrain anymore... if it does, then I blame it being early in the morning.

Copying the code from Ryan's post here:

class Customer {
    dummyProperty: string;
}

var map: { [email: string]: Customer; } = { };
map['foo@gmail.com'] = new Customer(); // OK
map[14] = new Customer(); // Not OK, 14 is not a string -- ACTUALLY, this compiles now
map['bar@hotmail.com'] = 'x'; // Not OK, x is not a customer

Playground

Apologies if this has already been raised, but I couldn't find a duplicate issue. Maybe this is now by design?

[RyanCavanaugh]

We changed the behavior here because (at runtime) numbers are implicitly converted to strings during index operations. Basically, a string indexer is a "superset" of a number indexer.

[dsherret]

@RyanCavanaugh ok, thanks! That's slightly annoying though... from what I see that change makes defining the type on an index useless. In my opinion, the runtime behaviour should not be taken into consideration when someone explicitly defines the index type. If someone wanted the current behaviour, I think it would make more sense for them to write:

var map: { [email: string | number]: Customer; } = { };

Oh well :(

[arusland]

@RyanCavanaugh could you explain why second assignment is incorrect?

interface SomeArray1 {
    [index: number]: string;    
}

var my1: SomeArray1;
my1["12"] = 12;
my1[12] = 12; // <-- why this line is incorrect but first assignment before is OK?

I think it's a violation of POLA principle

[RyanCavanaugh]

We don't treat numeric-looking string literals as numbers, for obvious reasons, so this is the same as writing my1['foo'] which a lot of people like to do to work around the type system. This is basically an escape hatch for when you don't want the type system involved.

This is implemented via the global type Object [effectively] having a string indexer that returns any, but using this implicit indexer is an error under --noImplicitAny.

[zjiekai]

@RyanCavanaugh

a string indexer is a "superset" of a number indexer.

I'm wondering why the following code compiles.

class Customer {
    dummyProperty: string;
}

var map: { [key: number]: Customer; } = {};

map[14] = new Customer();
map['map'] = new Customer();  // <-- Why does this line compile?

Playground

Update: It seems it's a problem of the playground. My local tsc raises TS7015: Element implicitly has an 'any' type because index expression is not of type 'number'.

[dsherret]

@zjiekai that's because the playground doesn't compile with the --noImplicitAny compiler flag.

[RyanCavanaugh]

FYI please don't drop questions into old issues - ask them on Stack Overflow. If you think you've found a bug, log a new issue.