And if you want to specialize a general string to a template litteral at runtime you cannot.
Most of the time you want to validate user strings/runtime generated strings. On most applications compile time strings are very few and not need validation. When you need validation of strings you generally need only runtime or both and then why duplicate the runtime validation with another compile time validation that take an alternative syntax?
This seems 1) a niche feature
And 2) a feature that users will misunderstand, the only dev I know which read about the feature think it works at runtime. Also I believe that existing template litteral do accept general strings I did a POC a few months ago so that's weird but maybe that TS can determine that a string is from runtime and then refuse it at compile time.
It's not as niche in web technologies as you might think.
Some domains that will benefit: ORM mappers, CSS style generation, configuration strings, path munging, localization.
> Also I believe that existing template litteral do accept general strings I did a POC a few months ago
... yes, template literals accept general strings. Like I said,
> Template literals that contain non-string-literal parameters will still generalize to string.
the new feature kicks in when all the parameters supplied to the template literal are value types themselves, or an OR of value types (I don't know if something even more expressive is supported).
I hope you try to understand better what TS is offering before you make uneducated criticisms of it.
> If my parameter only accept "foo" or "bar" and that at runtime I send an invalid input
calling a function with a general string argument when the parameter expects a string literal will have TS refuse to compile.