Normative: the TV of `\` NotEscapeSequence

[jmdyck]

Commit 138c9ef merged the Template Literal revision proposal, that removes the restriction on escape sequences in tagged template literals. In it, the syntax-directed operation TV is altered to return *undefined* if the subject of the operation contains a NotEscapeSequence.

However, the rules for Evaluation of TemplateLiterals (etc) don't allow for this possibility. They continue to assume that the result of TV is a sequence of code units.

We could make the Evaluation algorithms work again by applying ToString() to the result of TV, but what would be the point? Why would you ever use a NotEscapeSequence in a TemplateLiteral if you're just going to get the string undefined at the corresponding point in the resulting value?

It seems to me that from a usability point of view, the TV of a NotEscapeSequence should return the same as the TRV does (or something pretty close to that). Isn't that what's needed by the latex example at https://tc39.github.io/proposal-template-literal-revision/?

(Does test262 have any tests that examine the value of a TemplateLiteral containing a NotEscapeSequence? I don't see any.)

[bakkot]

Maybe I'm missing something - why is this a problem? My understanding is that tagged template literals aren't ever Evaluated; rather, the template parse node is passed through to ArgumentListEvaluation. And untagged templates are statically prevented from containing NotEscapeSequences.

[bakkot]

Maybe I'm missing something - why is this a problem? My understanding is that tagged template literals aren't ever Evaluated; rather, the template parse node is passed through to ArgumentListEvaluation. And untagged templates are statically prevented from containing NotEscapeSequences.

[jmdyck]

Ah, I see... a tagged template is evaluated without evaluating the TemplateLiteral per se. Thanks!

So a tag-function that's prepared to accept NotEscapeSequences in the TemplateLiteral would probably just ignore all the cooked strings of the template object, undefined or not?

Looking at the proposal again, I see now that that's what it says. (When I read it before, I thought it was saying something like "if the cooked value is undefined, you can use the raw string instead".)

So now what I'm wondering is: if the tag-function is probably going to ignore the TV values anyway, is there a particular advantage to making TV of NotEscapeSequence be *undefined*, as opposed to say, empty string?

[jmdyck]

Ah, I see... a tagged template is evaluated without evaluating the TemplateLiteral per se. Thanks!

So a tag-function that's prepared to accept NotEscapeSequences in the TemplateLiteral would probably just ignore all the cooked strings of the template object, undefined or not?

Looking at the proposal again, I see now that that's what it says. (When I read it before, I thought it was saying something like "if the cooked value is undefined, you can use the raw string instead".)

So now what I'm wondering is: if the tag-function is probably going to ignore the TV values anyway, is there a particular advantage to making TV of NotEscapeSequence be *undefined*, as opposed to say, empty string?

[bakkot]

In most cases that's what I'd expect, yes. The cooked values of sections not containing a NotEscapeSequence are available if necessary; those of sections containing a NotEscapeSequence are undefined, which isn't all that useful but does at least let you know that the section had something weird in it.

[bakkot]

In most cases that's what I'd expect, yes. The cooked values of sections not containing a NotEscapeSequence are available if necessary; those of sections containing a NotEscapeSequence are undefined, which isn't all that useful but does at least let you know that the section had something weird in it.

[bakkot]

But for example

String.raw`\xyz`

works just fine, since String.raw does not even look at the cooked values.

[bakkot]

But for example

String.raw`\xyz`

works just fine, since String.raw does not even look at the cooked values.

[jmdyck]

I guess if a tag-function is not prepared to handle NotEscapeSequences, *undefined* lets it know (more easily than would empty string) that the template literal has 'bad' input.

[jmdyck]

I guess if a tag-function is not prepared to handle NotEscapeSequences, *undefined* lets it know (more easily than would empty string) that the template literal has 'bad' input.

[jmdyck]

Okay, closing this then.

[jmdyck]

Okay, closing this then.