EcmaScript 2018. Template Literal Revision

Finishing the series of our articles devoted to EcmaScript innovations, - "Object.values/Object.entries", "String padding", and ".getOwnProperty and trailing commas", we want to talk a little bit about the plans for the next release of ES 2018 or ES Super next. Since the technical committee of the JavaScript language specifications yearly make additions we are hopefully to expect new features in the not-too-distant future.

TC39 Process

First of all, let's wrap our heads around the fact how the proposal gets eventually included into the language's spec. For this purpose it has to go through some stages from 0 to 4. Now let's see what happens during those stages.

Stage 0 is the Strawman stage. It's the initial stage for input. The ideas for EcmaScript are being freely submitted by the TC39 members or the registered contributors.

Stage 1 is the Proposal stage. It's a formal proposal for the feature where the responsible person(-s) is identified and makes a case for the addition. The solution and any major challenges are being recognized and described.

Stage 2 is the Draft stage. It's a first version that might be included in the spec. At this stage the syntax and semantics must be formally described as fully as possible.

Stage 3 is the Candidate stage. If the proposal reached this stage it means that it's mostly finished but has to be tested for further refinement.

Stage 4 is the Finished stage. The addition is ready and the proposal can be included in the EcmaScript standard.

Short Overview

At this point, we know about one feature proposed by Tim Disney that is currently at stage 4. It's called Template Literal Revision its main point is to give more syntactic freedom to the innards of tagged template literals.

Let’s start with getting clear about what tagged template literals are. They give you an opportunity to make a function call by mentioning a function before a template literal.

 > String.raw`\u{4B}`
'\\u{4B}'

String.raw is a tag function which receives two versions of the fixed string pieces, called template strings, in a template literal. The first version is cooked - the escape sequences are interpreted (`\u{4B}` becomes 'K'), and the second version is raw - the escape sequences are a normal text (`\u{4B}` becomes '\\u{4B}').

For example:

 function tagFunc(tmplObj, substs) {
    return {
        Cooked: tmplObj,
        Raw: tmplObj.raw,
    };
}

And with the use of the tag function:

 > tagFunc`\u{4B}`;
{ Cooked: [ 'K' ], Raw: [ '\\u{4B}' ] }

The issue is that even with the raw version you don’t have total freedom within template literals, because some sequences of characters aren't legal after a backslash.

For example: \x starts a hex escape, which must look like \x4B, etc.

To go around this you need to drop all syntactic restrictions related to escape sequences. That way the illegal escape sequences will just show up verbatim in the raw representation. And in the cooked representation every template string with an illegal escape sequence is an undefined element.

 > tagFunc`\uu ${1} \xx`
{ Cooked: [ undefined, undefined ], Raw: [ '\\uu ', ' \\xx' ]

Wrapping up

So, this is it with EcmaScript for now. If you have found these series of articles useful or you have any questions or suggestions, please, write your feedback. We are looking forward to your comments and we'll keep you posted.