Repository navigation
Concatention of string index templates ${number}${string}${number} is not additive w.r.t. accepted strings. #46124
Description
Bug Report
🔎 Search Terms
String index templates
Template String Pattern Index Signatures
🕗 Version & Regression Information
Seen on 4.4.3
- String Index Templates are a new feature with 4.4.2/3
⏯ Playground Link
💻 Code
// Violates additivity
type T1 = Record<`${string}`,any>
const t1:T1 = {'':0} // pass (expected)
type T2 = Record<`${number}`,any>
const t2_1spaces:T2 = {' ':0} // pass (expected)
type T3 = Record<`${number}${string}`,any>
const t3_1spaces:T3 = {' ':0} // pass (expected)
type T4 = Record<`${number}${string}${number}`,any>
const t4_0spaces:T4 = {'':0} // fail (expected)
const t4_1spaces:T4 = {' ':0} // fail (expected)
const t4_2spaces:T4 = {' ':0} // fail (UNEXPECTED) <------------
const t4_3spaces:T4 = {' ':0} // pass (expected)
const t4_4:T4 = {'11':0} // fail (UNEXPECTED) <------------
const t4_5:T4 = {'111':0} // pass (expected)
type X<T extends number|string> = Record<T,any>
type NS = `${number}${string}`
type N = `${number}`
type NSN = `${NS}${N}`
type A=X<NS>
type B=X<N>
type C=X<NSN>
const a:A = {'1':null} // pass (expected)
const b:B = {'1':null} // pass (expected)
const c:C = {'11':null} // fail (UNEXPECTED) <---------------------------🙁 Actual behavior
If two templates are concatenated, that result will not accept all concatenations of originally accepted strings.
(More narrow assessment: ${number}${string}${number} should be equivalent to ${number}${string}, but isn't.)
🙂 Expected behavior
If two templates are concatenated, that result will accept all concatenations of originally accepted strings.
(More narrow assessment: ${number}${string}${number} should be equivalent to ${number}${string}.)
Activity
ahejlsberg commentedon Sep 29, 2021
This is working as intended, but I agree it may be a bit surprising. Quoting from the original PR for this feature, here's how matching works:
Note the last sentence. When placeholders are immediately next to each other, the first placeholder just infers a single character from the source. The kind of placeholder being inferred to doesn't matter for determining the inferred text, it only matters for validating the text. The rationale for the single character behavior is to provide a mechanism for picking apart string literals using inference in conditional types, as in
S extends `${infer Char}${infer Rest}` ? .... It is less useful with non-generic placeholders, but the behavior is the same for consistency and because we use a single matching algorithm. That algorithm is fairly simple, but that is by design. We really don't want to turn our type system into another RegEx engine.craigphicks commentedon Sep 29, 2021
Thanks for the detailed answer and the pointer to the very clear documentation. Now I understand why a final ${string} can accept the empty string and can code accordingly.