Repository navigation
Do not allow surrounding spaces to be counted as part of ${number} templates in template index strings #46109
Description
Activity
- changed the title
[-]Do not allow spaces around ${number} templates in template index strings [/-][+]Do not allow surrounding spaces to be counted as part of ${number} templates in template index strings [/+]on Sep 28, 2021 Can be simplified to
const a: `data-${number}` = "data-1"; // OK // No errors const a1: `data-${number}` = "data- 1"; const a2: `data-${number}` = "data-1 "; const a3: `data-${number}` = "data- 1 "; const a4: `data-${number}` = "data- ";
Reacted by Craig P Hicks and Daniel RasmussenOh wow this an even better example for my list of surprising behaviors of
`${number}`in #41893! I'm still not quite able to internalize the interpretation of`${number}`meaning "some string that converts to a finite number", but apparently that's what it means (as opposed to "the type of`${n}`whennis a finite number").Reacted by Craig P HicksJoe Calzaretta (@jcalz) - Thanks for link to 7.1.4.1.2 Runtime Semantics: StringNumericValue, that is very informative. So the behavior is intended to match some formal standard - as I suspected but wasn't sure. (I also enjoyed you list of examples!)
For a user on the consuming end of the data, if they want to correctly decode the pattern suffix to disambiguate the many-to-one mapping of strings to numbers, they must use of algorithm listed in
[7.1.4.1.2 Runtime Semantics: StringNumericValue]. I see that a possible source of confusion and errors. That risk would be mitigated by employing a simple one-to-one mapping.Having a many-to-one mapping of keys strings to semantic keys, before using the keys to lookup the value in the object map seems anti intuitive and error prone. But the original problem lies in JS, not TS.
On the other hand, if TS is going to impose some strict typing on the keys for arbitrary integers, why not go the whole way and allow specification of a one-to-one map? For an explicit limited range of integers it is already possible:
type CountingIntegers = "1"|"2"; type FooN = Record<`foo${CountingIntegers}`,any>Maybe the feature request should be for a temple-key-string use specific intrinsic utility type "CountingIntegers" allowing all nonnegative integers up to
Number.MAX_SAFE_INTEGER(or maybe convertible to bigint). That is narrow enough to be safe and easy to implement, is extremely simple for a user to understand completely at a glance, and has practical value in eliminating misunderstandings.Thanks to Joe Calzaretta (@jcalz) pointing out 7.1.4.1.2 Runtime Semantics: StringNumericValue, it is now clear within a shadow of a doubt that the "surrounding space" behavior is "working as intended". So I will close this issue.
I’m not sure… I’d really like to hear someone officially say that this is intentional. I’m just an interested bystander.
Reacted by Andrii Dieiev and Craig P HicksSame here regarding whitespace.
While100.1or even1e3are really looking as number literals including whitespace doesn't look expected from usage perspective, but that's IMHO.Reacted by Craig P HicksThis is very surprising to me and seems undesirable, but I’ll let Anders Hejlsberg (@ahejlsberg) have the definitive word.
Reacted by Joe Calzaretta and Craig P HicksYeah, we're basically just relying on JavaScript's intrinsic string-to-number conversion to validate
`${number}`placeholder values--and it permits leading and trailing whitespace. Also, strangely, it permits empty strings and strings with only whitespace and returns0for those.I agree it makes more sense to not permit any whitespace and in particular to not permit empty strings. It's technically a breaking change, but can't imagine many types depend on it.
Reacted by Andrew Branch, Martin Johns, Andrii Dieiev, Craig P Hicks, Kevin Ryan, Sindre Sorhus, Connor White, Kagami Sascha Rosylight, dmitrysteblyuk, Hans Brende and 1 moreReacted by Craig P Hicks and Hans BrendeI'm still not quite able to internalize the interpretation of
${number}meaning "some string that converts to a finite number"And I'm still hung up on "finite"!
To me, this behavior also seems strange:
1e999 satisfies number // Passes! `${1e999}` satisfies `${number}` // Error: Type "Infinity" does not satisfy the expected type `${number}` type Oops<N extends number, IsItReallyFinite extends `${number}` = `${N}`> = IsItReallyFinite 'Infinity' satisfies Oops<1e999> // Passes...
I'd expect the correct definition to be "some non-empty, trimmed string that converts to a non-NaN number".
Either that, or the type of
`${N}`whereN extends numbershould widen to`${number}` | 'Infinity' | '-Infinity'. (Either way would resolve the inconsistency, but the former seems like the obvious approach.)Yeah, we're basically just relying on JavaScript's intrinsic string-to-number conversion to validate
`${number}`placeholder values--and it permits leading and trailing whitespace. Also, strangely, it permits empty strings and strings with only whitespace and returns0for those.I agree it makes more sense to not permit any whitespace and in particular to not permit empty strings. It's technically a breaking change, but can't imagine many types depend on it.
Anders Hejlsberg (@ahejlsberg)
Okay, but why is TypeScript then handling empty strings and whitespace strings differently?
type ThisIsTrue = " " extends `${number}` ? true : false; type ThisIsFalse = "" extends `${number}` ? true : false; const thisIsZero = Number(" "); console.log(thisIsZero); const thisIsAlsoZero = Number(""); console.log(thisIsAlsoZero);
Suggestion
🔍 Search Terms
Template String Pattern Index Signatures
Template Index Strings
✅ Viability Checklist
My suggestion meets these guidelines:
Actually it would change the typescript behavior as it was released - maybe better now than later?
The current behavior might be more bug than feature.
⭐ Suggestion
Not allowing spaces would reduce typing mistakes.
📃 Motivating Example
Modification of the example feature explanation in the handbook:
playground
💻 Use Cases
Using it to catch unintended key entries.