Closed jmdyck closed 3 years ago
The intent was to distinguish between abstract sequences of code units and actual string values which are ECMAScript language runtime values. You should have to have the full semantics of ECMAScript strings available in order to lex/parse ES code or to validate static semantic rules.
From that perspective, the direct use of TV sequences as string values like shown above is a spec. bug. The fix would be language like that shown as the alternative.
You should have to have the full semantics of ECMAScript strings available in order to lex/parse ES code or to validate static semantic rules.
(Presumably you mean "You shouldn't".) That seems like a plausible reason, except:
I am also curious, it seems fine to me to just always use string values (as long as it's clear that implementations don't need to use actual JS strings, which I think it is, given the existing loosyness @jmdyck points out).
The current editor group talked about it and is weakly split. @michaelficarra and @syg mildly prefer the status quo, @ljharb mildly prefers getting rid of the distinction. Does anyone have a strong reason to prefer one or the other?
As a data point, WHATWG's Infra defines a string as "a sequence of unsigned 16-bit integers, also known as code units. A string is also known as a JavaScript string." I think while aligning wouldn't be strictly necessary, getting rid of the distinction would bring some simplification to the spec.
This issue was resolved with the merge of PR #2018.
The spec defines SV, TV, and TRV to return a sequence of code units. But a String value is a sequence of code units. So why not define SV, TV, and TRV to return a String value?
Note that TemplateStrings appears to assume that TV and TRV do indeed return Strings. E.g., it says
and not