Do not allow surrounding spaces to be counted as part of ${number} templates in template index strings

Suggestion

🔍 Search Terms

Template String Pattern Index Signatures Template Index Strings

✅ 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.

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:

interface Options {
    width?: number;
    height?: number;
}

let a: Options = {
    width: 100,
    height: 100,
    "data-1": true, // Error! 'data-blah' wasn't declared in 'Options'.
};

interface OptionsWithDataProps extends Options {
    // Permit any property matching 'data-${number}'.
    [optName: `data-${number}`]: unknown;
}

let b: OptionsWithDataProps = {
    width: 100,
    height: 100,
    "data-1": true,       // Works!
    "data- 1": true,       // Passes but might be better off failing
    "data-1 ": true,       // Passes but might be better off failing
    "data- 1 ": true,       // Passes but might be better off failing
    "data- ": true,       // Passes but might be better off failing  (no number at all)

    "unknown-property": true,  // Error! 'unknown-property' wasn't declared in 'OptionsWithDataProps'.
};

playground

💻 Use Cases

Using it to catch unintended key entries.

[ahejlsberg]

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 returns 0 for 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.

[andrewbranch]

This is very surprising to me and seems undesirable, but I’ll let @ahejlsberg have the definitive word.