Interpolating values matching template literal type interpolations does not necessarily result in a string assignable to the template literal type

[TomerAberbach]

🔎 Search Terms

template type, template literal, substitution, mental model, parity, roundtrip, assignable, interpolation, string, constant

🕗 Version & Regression Information

This is the behavior in every version I tried, and I reviewed the FAQ for entries about... I couldn't find any FAQ entry about template literal types.

⏯ Playground Link

https://www.typescriptlang.org/play/?ts=5.9.3#code/PTAEHUHsCcGsGcBQBjSA7eAXUAzAltFgFyhbR5oDmoAvKAOSgC09K6WpApqmgCYloArgFsARp2i1QABjYZsmABYF+pTOSpT6AQ1Y8O2kgAMAJAG8yFSgF9moc0LETbTexfVXrRqabP5CmC5u8NzovEHmSipeiIggoAAikJzwoGiQ2ADuMLCgABScAG6caKBKkIKUiqBG-lgAjEYANDUhPLyNLdp8NVHQHd7a0JykgqKYAJ4ADimgkDg1dZjNraF8K928vcr9K8PwM8iYeMUANhMAlHIcS-VazHrs2G1hd3Sy+go7HVq619iiYzmSxUCJmRziaBgkE2bx0Xy3aFrDpgvoooz-UDIIHuDQ2OwOESQ6EeUFwmrmRgsMHSME6egxT6gVS+GFgiHOAm4zzkql2aR2AAerCAA

💻 Code

// Works
const first: string = ' -'
const second: number = 0
const third: string = 'a'
const a: `${string} - ${number} - ${string}` = `${first} - ${second} - ${third}`

// Does not work (even though `first1`, `second1`, and `third1` are subtypes of `first`, `second`, and `third`, respectively)
const first1 = ' -'
const second1 = 0
const third1 = 'a'
const b: `${string} - ${number} - ${string}` = `${first1} - ${second1} - ${third1}`
const c: `${string} - ${number} - ${string}` = `${' -'} - ${0} - ${'a'}`
const d: `${string} - ${number} - ${string}` = ' - - 0 - x'

🙁 Actual behavior

The last block of assignments does not typecheck.

That's wrong because each of the template string interpolation types (string, number, and string) was replaced with a value that's assignable to the interpolation type.

It's also wrong that making the types of first, second, and third more specific (i.e. subtypes) makes the code not typecheck anymore. That's a violation of the Liskov substitution principle.

🙂 Expected behavior

The last two assignments should typecheck for the reasons stated before.

Additional information about the issue

My mental model of template literal types is "if I replace each interpolated type placeholder with a value that is assignable to it, then I will end up with a string that matches the template literal type".

This seems to not be generally true, but I don't really know what other mental model would make sense. If that's not the mental model, then what is? How do I know if a given string value is assignable to a given template literal type?

[jcalz]

Looks like the same basic issue as #61990

[TomerAberbach]

Yeah, agreed, it seems like basically the same issue.

I guess I'm noting what I feel is a "bug" in the mental model here, but I'll leave it to y'all to decide if/how to merge these two issues

[RyanCavanaugh]

#61990 (comment)

The mental model here is that template strings are always greedily anti-greedily[?] matched, so matches which require backtracking are not going to work like you would expect if you thought of them like regexes. So when you have

`${string} - ${number} - ${string}`
' - - 0 - x'

TS is looking to try to match that first - as soon as it can, "" is a string, so then tries to match the next - as number, which fails

[jcalz]

Isn't that lazy matching? Greedy means it keeps consuming until it can't anymore (so it would be the last possible match) whereas lazy means it stops consuming as soon as it can (so it would be the first possible match). And what about the other deadly sins? What would "wrathful matching" be?

[RyanCavanaugh]

It's trying to finish matching as soon as possible, so... impatient matching?

[TomerAberbach]

Gotcha, are y'all moved at all by my Liskov substitution principle observation? It's pretty odd that replacing a type with a subtype causes the code to stop typechecking

[jcalz]

#60512 (comment)

Welcome to the TypeScript Unsoundness Support Group! I'm @jcalz and I have been a member for seven years. Sorry that there's no visual presentation this week. I put my laptop in the trunk of my car, and I drove the car to the meeting, but somehow the laptop stayed behind. Anyway today we'll be writing our own version of the Serenity Prayer to align with the TypeScript Language Design Non-Goals.

EDIT: this is indeed not a soundness issue but a completeness issue. The Incompleteness Support Group is meeting next week but nobody knows where it’s going to be.

[RyanCavanaugh]

Failure to allow the assignment isn't a soundness problem, it's a completeness problem.

Template literals weren't designed to be a regex engine (from the PR: "a simple form of string pattern matching") so cases where a regex engine (or similar) is necessary aren't super compelling. The motivating use cases are things like "getFoo" <-> "foo" where there aren't any significant parsing ambiguities or need for lookahead.