Allow concatenated strings to be cast as const type

[Lutymane]

Suggestion

🔍 Search Terms

Concatenated strings const type

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Allow as const cast to be applied to concatenated string literals like so:

// s0 would be 'ab'
const s0 = ('a' + 'b') as const;

https://www.typescriptlang.org/play?#code/FAehAIGcAZwdwPYFcA2ATcAjApuA5AIaZ7ADGCAdpAC5SwC84AFIXuANT7ECU4Bk4clWoBuYKAiQAjOACWAwsTKUaUGY0Vt+glaKA

📃 Motivating Example

It's convenient to split a long string into multiple concatenated lines to enhance code readability, so as const cast should work for it as well.

💻 Use Cases

Currently only a single string is allowed to be cast to its literal type. So as a workaround you just sacrifice code readability and make multiple strings into one:

'a' + 'b' => 'ab'

[fatcerberus]

It's convenient to split a long string into multiple concatenated lines to enhance code readability

This is why I've always wished JS supported splitting a string into multiple adjacent literals as in C, e.g. "a" "b" compiles down to "ab"

[Josh-Cena]

"a" "b" is so error prone—I've seen many Python programmers complaining that missing a comma in an array literal does not lead to an error but generates different behavior.

What's undesirable about this anyway?

const longLiteral = "a\
b";

[fatcerberus]

@Josh-Cena The continuation lines can’t be indented.

[jcalz]

Duplicate of #44905

[Lutymane]

@jcalz I don't believe my issue is a duplicate, because it's specifically targeted for concatenating literal values, not variables with literal types. And the purpose is to provide convenience for the coding. The argument made by ahejlsberg on that issue doesn't seem to apply here as well, because strings will not change their display value, so "a" + "b" will always remain "ab" not something else like in case with numbers: 2 + 3 will be 5, not 23. So there's absolutely no need to handle any unions or other operators