type ${number} cannot be used to index numeric index signature

[ajafff]

TypeScript Version: 4.2.0-dev.20201209

Search Terms:

Expected behavior:

type ${number} can be used to index numeric index signature

Actual behavior:

Error: Element implicitly has an 'any' type because index expression is not of type 'number'.

Related Issues:

Code

declare let t: `${number}`;

declare let obj: {
    [key: number]: number;
}

const v = obj[t];

Playground Link: Provided

[weswigham]

...but should it? ${number} admits strings like "-1.0e1", which a number index signature does not (since such a string, while parseable as a number, does not fill a numeric slot on the object!).

[ajafff]

I recall that I read something about the requirement for ${number} in template literal types to round-trip (parsing as number and stringifying gives the same string).
But testing with const a: `${number}` = '1.0'; shows that this is not the case.

[RyanCavanaugh]

The round-tripping is not a requirement, so @weswigham 's analysis is correct

[jcalz]

@RyanCavanaugh said

The round-tripping is not a requirement

Hmm, seems like it should be, right? I'd expect `${number}` to correspond exactly to those values `${n}` where n is of type number. Of course, we already look the other way with things like NaN and Infinity, so maybe not. In any case, has the round-trip functionality actually been discussed and declined? Or did it merely not get implemented yet? Is there an existing issue to track it? If not, should I open one?

[RyanCavanaugh]

Hmm, seems like it should be, right? I'd expect ${number} to correspond exactly to those values ${n} where n is of type number

This would imply that "1.0" wouldn't be a valid ${number}, which I think would be extraordinarily surprising.

[jcalz]

Wow, my intuition is exactly the opposite; could you articulate why it would be surprising? You must be looking at the class of valid string-to-number inputs, while I'm looking at the class of valid number-to-string outputs, and both of us are thinking "yep, that's the natural meaning of `${number}`". What's the intuition that drives your view?

Mine is that template literal types should correspond to (untagged) template literal values. Such template literals can consume numbers and produce strings, but they don't consume strings to produce numbers. If "1.0" and "0xfacade" are valid `${number}` values, then the type `${number}` doesn't have much, if anything, to do with template literals at all. It's more like "the strings s where Number(s) or +s is not NaN". It gets worse for a type like `foo${number}bar`: you need to say something like "those strings `foo${s}bar` where s is a string where +s is not NaN", instead of the much more straightforward "those strings `foo${n}bar` where n is a number".

Furthermore, the set of valid number-to-string outputs has a use case we already care about in TypeScript: "numeric" object indices. And while the set of string-to-number inputs might be useful, we don't currently have a string-to-number type function (as in #26382) to use with it. So I'd be interested in seeing use cases where the prohibition of "1.0" and "0xfacade" would break things.

[RyanCavanaugh]

I ran a poll and most people seem to have the reverse interpretation https://twitter.com/SeaRyanC/status/1420059847156928512

[jcalz]

Oh, well, 78.6% of respondents are wrong! Kidding, kind of. I guess `${number}s` don't lie! But I wonder if you'd have gotten different results if you had asked about

let s4: `${number}%` = "0xfacade%"; // okay or error
(arr: string[], idx: `${number}`) => arr[idx]; // okay or error
let s5: `This sentence is ${boolean}` = "This sentence is 0"; // okay or error
let s6: `${100.0}%` = "100.0%"; // okay or error
let s7: `${number}%` = "              333              %"; // okay or error

instead. In any case, this really makes me wish we had a different notation for strings-that-are-coercible-to-finite-numbers (maybe a new intrinsic type like type numericLiteralString = intrinsic) because the current notation is hard to square with how it's being used.

[ruojianll]

I think where ${number} appeared in template literal types should be correspond to js or ts number literal in ECMAScript https://tc39.es/ecma262/multipage/ecmascript-language-lexical-grammar.html#sec-literals-numeric-literals

[ahejlsberg]

The original issue reported here is fixed by #48837: Numeric index signatures are now applicable for indices of type `${number}`.

With respect to whether `${number}` should require that string literals round-trip, I think there are good arguments on both sides (as demonstrated above). My perspective is that round-trip checking adds little in terms of type safety. Most uses of the `${number}` type in conjunction with indexing really revolve around extracting and constraining index types, and less around checking user written string literals. One might even argue that round-trip checking wouldn't be strict enough because it still permits keys that lead to inefficient (and surprising) array representations at runtime. For example, "42.5" round-trips, but otherwise is treated as a non-numeric property that doesn't count towards the length of an array. If we really wanted strictness we'd need the ability to express non-negative round-tripping numbers. That, in combination with Ryan's point about how extraordinarily surprising it would be if "1.0" wasn't a `${number}`, makes me think we have the right compromise with the current semantics.