Description Arbitrary Index Signatures
#26797
Today we only support string and number index signatures.
We didn't have symbol index signatures (though it used to be allowed in string index signatures)
Now we have bigint - but we don't support those either.
People asked for index signatures on enums; but instead we said you could have a mapped type over an enum.
However, once you learn about index signatures, that's the intuitive thing to use (even if they're technically less-powerful than a mapped type).
As far as implementation goes, it is far reaching but it is reasonable.
Conceptually, they're quite similar to regular signatures; we just need to enforce a sort of priority.
When you index with something x[y], you have to try to apply the type of y against every index signature of x and union it to get the result.
As the duality, when writing an assignment x[y] = z, each type is intersected in the assignment.
There is some annoying behavior with these index signatures on literal types.
interface Foo {
[ index : "a" | "b" ] : string ;
[ index : "c" | "d" ] : number ;
}
// Error! But what's the deal!
class Bar implements Foo {
a = "a" ;
b = "b" ;
c = 10 ;
d = 20 ;
}
Bar hasn't declared explicit index signatures.
But when you have index signatures over a closed union, people will expect these to be equivalent. Seems bad.
What about "enum-yness"
Today, a mapped type over enums just flattens down to the numeric values that an enum maps to.
But with the current PR, we keep them distinct.
enum SomeEnum {
Zero ,
One ,
}
interface Foo {
[ index : number ] : number ;
[ index : SomeEnum ] : number ;
}
Here, we enforce that both of those index signatures are related to each other.
This also doesn't perfectly map to index signatures; you can't toggle optionality with ?.
If we started TypeScript over today, would we have both mapped types and index signatures?
Why have two ways to represent very similar concepts? Could we try to consolidate on mapped types?
[[Discussion around syntax and computed property names]]
"I think there's a story around index signatures for creating a set of known property names, and mapped types just being a template."
Reactions are currently unavailable
You can’t perform that action at this time.
Arbitrary Index Signatures
#26797
Today we only support
stringandnumberindex signatures.We didn't have
symbolindex signatures (though it used to be allowed instringindex signatures)Now we have
bigint- but we don't support those either.People asked for index signatures on enums; but instead we said you could have a mapped type over an enum.
As far as implementation goes, it is far reaching but it is reasonable.
When you index with something
x[y], you have to try to apply the type ofyagainst every index signature ofxand union it to get the result.x[y] = z, each type is intersected in the assignment.There is some annoying behavior with these index signatures on literal types.
Barhasn't declared explicit index signatures.What about "enum-yness"
Today, a mapped type over enums just flattens down to the numeric values that an enum maps to.
But with the current PR, we keep them distinct.
Here, we enforce that both of those index signatures are related to each other.
This also doesn't perfectly map to index signatures; you can't toggle optionality with
?.If we started TypeScript over today, would we have both mapped types and index signatures?
[[Discussion around syntax and computed property names]]
"I think there's a story around index signatures for creating a set of known property names, and mapped types just being a template."