New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add NoSubstitutionTemplate
to StringLiteral
Definition
#1399
Comments
Since this seems like it would allow, for example, backticks around strict mode pragmas and import specifiers, that makes it a feature request - which per CONTRIBUTING.md are best suggested in places other than this repo. Am i understanding the request correctly? |
That's one interpretation of it, I suppose. In my reasoning, a |
Perhaps @allenwb can speak to the motivations for not allowing template literals without substitutions anywhere quoted strings are allowed? |
Speaking only for myself, not for @allenwb . Untagged template literals without substitutions are just a degenerate case along two dimensions.
These two regularities make code easier to reason about. Btw @ljharb Another place this shows up is in the airbnb style guide and eslint settings. They discourage template literals that happen to be in exactly this degenerate case. Other than this, the airbnb style is good. At Agoric, we use the airbnb eslint settings with this change to template literal policy. |
@erights the rationale there is that a substitutionless template literal is more likely to be a bug (forgetting an interpolation) than an intentional string, but noted. |
As https://ponyfoo.com/articles/template-literals-strictly-better-strings elegantly argues, there are many good reasons to use a substitutionless template literal. Could the default be changed? |
Turning this around, I would think that there should never be a position in which a substitutionless template literal is legal but a template literal with a substitution is not. Which suggests that substitutionless templates should not be usable as property names or directives. |
@bakkot by the very nature of having different tokens for them in the grammar, they can and should behave differently. Why needlessly restrict the utility of The idea is that a
I don't think this necessarily follows. A substitutionless template literal is quite different from a template literal with substitutions in it, with not the least important of reasons being that the substitutionless template literal is invariable and safe to use at "compile" time, whereas template literals with substations may not be as the interpolated sections can vary. |
I don't think the composition of the formal grammar matters much here. When using js, we don't call arrow function arguments "covered parenthesized expressions" because the composition of the grammar that allows both |
@devsnek point taken.
Is it not reasonable to say that, similarly, a string literal (string without interpolation or concatenation) with "backtick" quotes, double quotes, or single quotes is still a string literal? It's possible for a thing to be categorized as more than one thing. In this case, a |
Given that this would need to be a new proposal, I'm going to close it per https://github.com/tc39/ecma262/blob/master/CONTRIBUTING.md#creating-a-new-proposal. |
Some teams opt to use exclusively template strings in their code (see template literals are strictly better strings for some reasoning).
This is almost supported by ECMA, but for the fact that
StringLiteral
is expressly defined as either a single quote or double quote string, excludingNoSubstitutionTemplate
s.I contend that adding
NoSubstitutionTemplate
s to the definition ofStringLiteral
will bring the benefit of allowing teams to completely opt to use only template strings instead of mixing quote marks, while having very little risk or downside, if any at all.NoSubstitutionTemplate
s by nature are completely defined at "compile" time, essentially being exact same in functionality as standardStringLiteral
s. Let's make it so in the grammar as well?The text was updated successfully, but these errors were encountered: