Restrict template literal interpolation expressions to strings
## Search Terms "template literal" There are many hits, some which seem related, but everything I could find was a much bigger ask or wider in scope ## Suggestion Add a compiler option to enforce using only strings in ES6 string template literals ## Use Cases When using string literals, any variables are coerced to strings, which can lead to undesirable behavior. As far as I can tell there's no way to avoid this behaviour. In the spirit of tying everything, I'd prefer that only actual `string` types are permissible for use in string templates to avoid accidental coercion by passing null, undefined or object types that may have unexpected string representations, and force users to explicitly convert them to strings. ## Examples For example: ``` function formatName(name: string | null): string { return `Name is: ${name}`; } formatName(null) === "Name is: null" ``` Ideally the compiler would fail since `name` can be null. ## Checklist My suggestion meets these guidelines: * [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code * [x] This wouldn't change the runtime behavior of existing JavaScript code * [x] This could be implemented without emitting different JS based on the types of the expressions * [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.) * [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/
Posted by jamietre on Mar 6, 2019, 3:15 PM
Tags
Related issues
- [BUG] Cowork (Windows): all Plan9 shares fail with "Plan9 mount failed: invalid argument" after Windows update KB5124008 (26200.9445) — uninstalling the KB fixe
- Feature Request: Auto-resume CLI session when usage limit resets
- Please deobfuscate the Python
- [Bug] MLX version of Gemma 4 26B fails to load: "Model type gemma4 not supported" (macOS)
- # 233 Developers Discussed Abandoning the Office Add-in Platform — An Open Letter on the Office.js Stability, Security & Trust Crisis
- [FEATURE] Allow users to configure which shell the Bash tool uses or inherit initial shell
Raise real-world problems, find people facing the same issue, and discuss solutions.4,000 issues0 comments
reliability (Software)
[BUG] Cowork (Windows): all Plan9 shares fail with "Plan9 mount failed: invalid argument" after Windows update KB5124008 (26200.9445) — uninstalling the KB fixe
Feature Request: Auto-resume CLI session when usage limit resets
Please deobfuscate the Python
[Bug] MLX version of Gemma 4 26B fails to load: "Model type gemma4 not supported" (macOS)
# 233 Developers Discussed Abandoning the Office Add-in Platform — An Open Letter on the Office.js Stability, Security & Trust Crisis
[FEATURE] Allow users to configure which shell the Bash tool uses or inherit initial shell
Admin Materials and Surfaces
AMD Support
Restrict template literal interpolation expressions to strings
## Search Terms "template literal" There are many hits, some which seem related, but everything I could find was a much bigger ask or wider in scope ## Suggestion Add a compiler option to enforce using only strings in ES6 string template literals ## Use Cases When using string literals, any variables are coerced to strings, which can lead to undesirable behavior. As far as I can tell there's no way to avoid this behaviour. In the spirit of tying everything, I'd prefer that only actual `string` types are permissible for use in string templates to avoid accidental coercion by passing null, undefined or object types that may have unexpected string representations, and force users to explicitly convert them to strings. ## Examples For example: ``` function formatName(name: string | null): string { return `Name is: ${name}`; } formatName(null) === "Name is: null" ``` Ideally the compiler would fail since `name` can be null. ## Checklist My suggestion meets these guidelines: * [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code * [x] This wouldn't change the runtime behavior of existing JavaScript code * [x] This could be implemented without emitting different JS based on the types of the expressions * [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.) * [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/
Comments (0)
No comments yet. Start the discussion.