tagged template literals should be allowed (for completeness)

From the current README:

The following are not supported due to a lack of real-world use cases:

optional construction: new a?.()
optional template literal: a?.`{b}`
constructor or template literals in/after an Optional Chain: new a?.b(), a?.b`{c}`

For this issue I'd like to understand:

What are the reasons to NOT support tagged template literals?
If there's no great technical issues with allowing them, WHY NOT support tagged template literals?

For discussion purposes, I'll provide a somewhat silly & simple toy problem-esque example:

/*
Prompt - In as few characters as you can, write a function 'splitOrJoin' that satisfies
two requirements:

1) If a string is passed in, split it and return an array of individual words, for example:
splitOrJoin('split this into an array'); // ['split', 'this', 'into', 'an', 'array']

2) If an array is passed in, join each element with spaces and return the resulting string:
splitOrJoin(['join', 'this', 'into', 'a', 'string']); // 'join this into a string'
*/

// Now your first instinct might be to write something with a ternary
const splitOrJoin = input => input.split ? input.split` ` : input.join` `; // this works

// Or, you could write it slightly differently
const splitOrJoin = input => input[input.split ? 'split' : 'join']` `; // also works

// But then you realize they're actually the same length when removing unnecessary characters
splitOrJoin=i=>i.split?i.split` `:i.join` ` // 43 chars
splitOrJoin=i=>i[i.split?'split':'join']` ` // 43 chars

// Hmm, how else could we shorten it? Oh yeah! There's this new thing called optional chaining
const splitOrJoin = input => input.split?.` ` ?? input.join` `; // also would work

// or the shortened version
splitOrJoin=i=>i.split?.` `??i.join` ` // 38 chars

// There! That's about as short as I can think to make it right now.

Now, you might think that code-golf is stupid (and I'd of course avoid using this pattern in production code--or anywhere you'd like your code to be readable and easily understood for that matter); but the fact is: tagged template literals are valid syntax in JavaScript.

Therefore, if you can write i.split` ` I'd also expect you to be able to write i.split?.` ` for the sake of completeness. Hopefully you can see past the ridiculousness of the example to see the reasoning for this.

So I'd like hear some logical argument around the two questions asked in the beginning. What are the reasons to arbitrarily (seemingly) disallow use of tagged template literals in conjunction with optional chaining? If there are, technically, no sound reasons for not supporting tagged template literals, why not allow them just like they're already allowed elsewhere?

I'll start it off with a reason TO support tagged template literals.

I'll be honest; I was struggling, at first, to think of a real-world use case (other than code-golf, which is actually a thing that happens in the real world). However, I just thought of one possibility.

Suppose in the future (you want this feature to be as future-proof as possible, right?) there is far less need to transpile ES6 syntax to ES5 (i.e., Babel) as a greater and greater % of browsers in use provide native support. (Aside: Out of curiosity, here is the current state of support for template literals.)

In order to provide minifiers (such as UglifyJS) with all tools at their disposal to save bytes over the wire in your .min.js files, it might actually become important to support tagged template literals wherever possible, including after an optional chain--much like in the silly code-golf example.

For this issue I'd like to understand:

What are the reasons to NOT support tagged template literals?

If there's no great technical issues with allowing them, WHY NOT support tagged template literals?

Adding optional tagged template literal support is more spec text, although it is easy to do. Therefore, I’ve chosen to drop them by default, i.e. unless/until there is consensus for adding them.

In other words, in absence of a good reason for one way or the other, I’ve picked the laziest option for the spec writer and (I expect) the implementors.

@claudepache

@claudepache

Adding optional tagged template literal support is more spec text, although it is easy to do. Therefore, I’ve chosen to drop them by default, i.e. unless/until there is consensus for adding them.

I see; I guess I'm not too familiar with the process yet. Would it be a reasonable request to suggest that any explainers/spec text clarify that template literal support is not required but is recommended for completeness's sake?

In other words, in absence of a good reason for one way or the other, I’ve picked the laziest option for the spec writer and (I expect) the implementors.

I'd hope the example I gave, while perhaps not the most compelling of reasons, at least nudges implementations to include support for tagged template literals.

I do fear, however, that if template literal support is not required in the spec that browser/Node.js, etc. implementations would become fragmented, only complicating things; for example, it would lead caniuse.com to cover three different features:

template literal support
optional chaining support
optional chaining (followed by template literals) support

This would inevitably delay or prevent minifiers' ability to make use of their combining with optional chaining as in comment.

I'd probably be willing to accept that risk if it's at least strongly suggested to include template literal support, however.

Edit:
In any case, I had to get my thoughts on the matter out and I hope this issue will serve as a historical reference to any implementors deciding whether or not to add support for optional tagged template literals.

If anyone else can think of other use cases, feel free to jump in.

@ScottRudiger

@ScottRudiger I might be wrong, but to my knowledge, none of the JS spec is considered "recommended"; a feature is either in the language (meaning all JS engines will implement it) or not. For the reason you described, I don't think that type of thing would make sense in JS.

It's not just tagged template literals, there are lots of features that might be included here for the sake of completeness, like optional new, optional delete, and optional property assignment. Here's a previous discussion I started on the popularity of these features: #17 (The current state of the proposal is that optional delete is actually supported, I think.)

The way I think about this is that it's best to work incrementally, just like with code. A less ambitious proposal is inherently less controversial, so it'll make it through committee faster. Optional tagged template literals can always be added later. That's also why nullish coalescing is it's own proposal instead of being included here, even though the two are related. The case to be careful about, though, is when a proposal limits what changes can be done in the future. That's why so much thought has been put into avoiding the syntax clash between optional chaining and nullish coalescing, even though the two proposals are separate.

Optional chaining has been in stage 1 for over a year, despite significant work and despite it being very popular. For me, it's a bit frustrating watching it take so long, although it's certainly understandable that people want to get it right. There's already enough detail and controversy in the core feature that IMO it's best to keep it as simple as possible and leave any nice-to-have extensions for future proposals.

@alangpierce

@alangpierce

I might be wrong, but to my knowledge, none of the JS spec is considered "recommended"; a feature is either in the language (meaning all JS engines will implement it) or not.

I was imagining that to be the case. That's why I was thinking a benefit of requiring support would be to prevent different implementations supporting/not supporting the feature--a problem that seems to have contributed much complexity to JS in the past (for library writers/web devs/JS users in general).

It's not just tagged template literals, there are lots of features that might be included here for the sake of completeness, like optional new, optional delete, and optional property assignment.

I can definitely see your point regarding optional property assignment, as that is a separate feature that could be, and likely will be, discussed and separately introduced in another proposal down the line. However, I don't see tagged template literal support as necessarily a full-fledged feature on its own. It's more on the same level as optional function/method invocation, e.g., obj.meth?.() == obj.meth?.`` .

The way I think about this is that it's best to work incrementally, just like with code. A less ambitious proposal is inherently less controversial, so it'll make it through committee faster.

Thanks for the insight around the process for getting proposals through committee. I was surprised to see that @claudepache originally wrote this proposal over two years ago. As an aside, I'd like to commend the TC39 contributor/proposal writers as well as the TC39 members for their patience and persistence in trying to improve and extend JavaScript, with substantial time and effort on their parts.

The case to be careful about, though, is when a proposal limits what changes can be done in the future. That's why so much thought has been put into avoiding the syntax clash between optional chaining and nullish coalescing [...].

I totally agree; that's why I've been kind of obsessed with following and commenting in #51, #34, and #5, as I think it's very important to settle on a reasonable syntax for many reasons, including future considerations. (I'd encourage anyone reading to see those issues for discussion on syntax. Leave this thread to the issue at hand and I'll promise not to reiterate my preferred option here. 😉)

To address your point though, I don't think that requiring support for tagged template literals now does anything to limit future proposals, other than negating any need to introduce a proposal just to specifically add support in the future.

Conversely, I'd think my previous comment shows that requiring support now may actually save all involved from potential complexity and heartache if/when implementations diverge. 💔

I'm open to hearing what foreseeable changes, if any, could be limited by template literal support now, however. Let me know.

Thanks for your well-thought out reply.

@claudepache

I like @claudepache 's minimalism approach here: It seems less likely to lead to confusion. I don't think it's possible for us to create a fully "orthogonal" optional chaining feature here--there are lots of situations where you might want short-circuiting or optional chaining that would be pretty infeasible or excessively complicated. Ultimately, programmers will have to learn what's allowed.

At first sight, optional tagged template literal is tempting ”for completeness”. But on reflection, I think that:

a ?. `${x}` // undefined if a is nullish, a `${x}` otherwise

is about as reasonable or useful as:

a ?.* b // undefined if a is nullish, a * b otherwise

Also, one may also make sense of template literal optionally tagged, i.e. (random strawman syntax):

a???`${x}`// `${x}` if a is nullish, a `${x}` otherwise

To be precise, ”Optional tagged template literal support” may be subdivided in two cases (although I don’t think that it is a good idea to support one and not the other):

a?.b`c` (template literal appears inside an optional chain);
d?.`c` (template literal appears at the beginning of an optional chain).

I think the former must be supported; the latter i think is a totally separate feature.

In other words, when deciding what to support, i think there shouldn’t be anything we don’t support inside an optional chain - only things at the beginning of an optional chain (ie, the things that are optional)

i think there shouldn’t be anything we don’t support inside an optional chain - only things at the beginning of an optional chain (ie, the things that are optional)

I totally concur with this line of thinking. To me it seems like if the former (a?.b`c` ) is disallowed that optional chaining is kind of "stepping on" what one would normally expect to be allowed in JS; i.e., a.b`c` is already valid syntax so why is optional chaining preventing it?

I think the former must be supported; the latter i think is a totally separate feature.

However, I disagree--to a degree--with this. I think I already mentioned this (not quite awake yet), but a?.('c') can be considered equivalent to a?.`c` . Therefore, it's a separate feature in the sense that a?.c is a different feature from a?.['c'] is a different feature from a?.('c'). However, imo it's more like: because a?.('c') is a feature, I'd also expect a?.`c` to be a feature. They're literally the ~same thing.

i think there shouldn’t be anything we don’t support inside an optional chain

It depends whether a template literal found at the end of an optional chain is considered to be inside it or after it. Surely, for a spec guru it is inside, but for a lambda programmer?

This is not really a issue if the application of the incorrect thinking would necessarily lead to a TypeError (and this is why I consider that short-circuiting up to the end of the chain is safe even for those that do not understand it). But regarding template literals, someone could think of:

a?.b`c`

as an optionally tagged template literal:

(a == null ? `c` : a.b`c`)

(Personally, I don’t think it is a real problem, but it is worth raising the question.)

I think the former must be supported; the latter i think is a totally separate feature.

I disagree. For someone not versed in the spec details, it would seem like an arbitrary restriction or an inconsistency if some construct is allowed in some location of an optional chain, but not in another. (Yes, I’ve changed my mind since I’ve written #4 (comment).)

I think the former must be supported; the latter i think is a totally separate feature.

I disagree. For someone not versed in the spec details, it would seem like an arbitrary restriction or an inconsistency if some construct is allowed in some location of an optional chain, but not in another. (Yes, I’ve changed my mind since I’ve written #4 (comment).)

👍 Totally agreed; this is what I've been trying to say, but in better, more concise words than I can ever dream to think of 🤣. I'd also add: it seems like an arbitrary restriction or inconsistency if some construct is allowed in a <regular> chain, but not in an <optional> chain.

This is not really a issue if the application of the incorrect thinking would necessarily lead to a TypeError (and this is why I consider that short-circuiting up to the end of the chain is safe even for those that do not understand it). But regarding template literals, someone could think of:
a?.b`c`
as an optionally tagged template literal:
(a == null ? `c` : a.b`c`)

But I honestly don't see how they could think of that meaning if they have an understanding of either optional chaining OR tagged template literals (read the docs). If they wanted to achieve a == null ? `c` : a.b`c` they could write something like:

a?.b.`c` ?? `c`

edit: or even without knowing about the null coalescing operator's existence:

a?.b.`c` || `c`

I think debating whether "invocation" and "tagging a template literal" are the same is separate; I'm still grouping things into "optional X" and "X behind an optional chain" - I think that everything should work in the "X behind an optional chain" bucket identically to how it would work with "X behind a normal chain" (when X is not nullish, obviously), and I think that we can and should have distinct discussions about supporting "optional X" for any given X's.

@ljharb

@ljharb I'm still grouping things into "optional X" and "X behind an optional chain"

It’s not the first operation of the chain that’s optional, it’s the chain as a whole. (This is how short-circuiting works without resorting to artefact like Nil reference or abrupt completion.)

Moreover, I would claim that the existing spec'd behavior -- a?.() resulting in undefined if the a() function is nullish and can't be called -- is exactly the same situation as with tag functions: to properly handle this problem, both forms have to add some additional graceful handling of the undefined.

In the README of this repo, I’ve given two concrete examples for optional method calls. In the first one, no code is needed to handle the “problem”, because the problem is completely solved by the optional call. In the second example, nothing additional is needed in order to have “graceful” degradation—although in other similar cases, a simple ?? fallback would be added.

IOW, if this is useful/OK to expect this of usages of ?.(, then it should be equally useful/OK to expect it for usages of ?.`.

I don't see any compelling reason to favor/distinguish that undefined handling with one call form over the other. So I believe that argues for consistency here.

Until now, there haven’t been convincing use cases for optional tagged templates. Your use case might be the first one, but it has still too many “might”s for my taste.

Also, what you call consistency here is what I call completeness. Probably the reason is that I consider that “tagging a template” is not the same thing as “invoking a method”, even if both end up executing some function. (Other example of “(not) the same thing”: “constructing a class instance” (with new)—that one is not supported either, see #22.)

I’ve given two concrete examples for optional method calls...no code is needed

OK, fair enough, those two specific kinds of cases don't require the special handling.

But certainly ?.( will be used, or at least considered, for lots of other function calls where in most cases that handling will be necessary. So as a general feature for general usage -- which is what I would expect -- it does imply that extra handling.

Also, what you call consistency here is what I call completeness.

I don't object to that characterization.

with new—that one is not supported either

Though I personally don't care about (or often use) new, for completeness sake, it seems like it also ought to be supported, with the same undefined short-circuiting.

@getify

@getify Sorry I don't very understand the case you provide. If var x = string?.`${ somevalue }`; result in var x = undefined instead of var x = somevalue, it's likely your user's code will throw error in some other place. Doesn't it just introduce much pains compare to throwing TypeError in first place?

@hax

@hax I do not think it will lead to errors, I think it will prevent them.

As I said earlier, the chances that a tagged template being undefined, and then needing basic checks to see it's not a string/etc as expected to handle the error, are absolutely identical to the checks and handling you would have to do for any function call (or property access, for that matter) which was short-circuited to undefined.

If we can imagine those checks and handling for functions and properties, then we should be able to see that those patterns apply equally to tagged templates.

var obj = {};

var a = obj.?numberOne;
// safety guard in case of short-circuiting
if (typeof a == "number") {
  console.log(a + 41);
}

var b = obj?.fortyOne.?();
// safety guard in case of short-circuiting
if (typeof b == "number") {
  console.log(b + 1);
}

// if we do the other two, we should do this one too
var c = obj?.toNum?.`41`;
// safety guard in case of short-circuiting
if (typeof c =="number") {
  console.log(c + 1);
}

If you want to convince us, you should find a concrete scenario (or, better, a real-world use case) where an optional tagged template literal is useful and better than other alternatives. I am convinced that maybe it could happen that it might be useful someday to someone. But I am not at all convinced that a random occurrence of foo?.`bar` will not be more often a bug (i.e. a logic error from the programmer) than a useful expression.

Mere analogy to optional call is not sufficient. As a precedent, per #17, optional call has significant practical uses but optional construction has zero practical use.

@claudepache

@claudepache

Mere analogy to optional call is not sufficient.

I am not justifying the request based on that. I gave the use-case as justification for the request. (see below)

I am defending against the "won't this create worse errors" dismissal, which is misguided. As I've asserted and demonstrated, the "oops this is 'undefined' instead of the value I wanted" handling is identical with property accesses, function calls, and tagged template calls, which is to say you of course are going to in general have to do that for all 3 cases.

Just because you refer to a few narrow use-cases cited which wouldn't need that extra handling does not justify your broader position -- or what I'm inferring is your position -- that tagged templates are of a different category, and thus don't hold weight here.

This is a feature you're adding to JS, the most widely used language on the planet, and that means people are going to use it for all kinds of general coding, not just a couple of specific scenarios you cite. That means they're going to use them with functions which return values, and if the short-circuting to undefined happens, it means that code is going to need to gracefully handle that because undefined won't be what they expected, and an error could happen if it's not handled.

They'll use ?.( in thousands of different call scenarios, and they'll write the basic guarding logic to handle the short-circuit scenario. That's all perfectly reasonable. And the exact same thing could (and should) be said of doing so with template tags.

If you want to convince us, you should find a concrete scenario (or, better, a real-world use case)

I already gave you a concrete scenario. The type-annotation library (called TypL) that I am building, uses template tags for annotating the types of literals... these tags both perform type assertions as well as value-type coercions. These tags are read by a compiler (if you choose) to do compile-time type linting (like TS), but the tags can also be used in the runtime code for dynamic value-type assertions.

The use-case again is:

var x = number?.`42`;     // **** if the operator is extended for template tags
if (typeof x == "number") {
  // do something with the number
}
else {
  // handle the lack of a number gracefully
}

If number tag function is defined and in scope, the tag works fine. If it's not there (they failed to load the tag assertions lib, etc), the only way to "handle" this, if the ?.` operator usage is not extended as requested, is:

try {
   var x = number`42`;   // if the operator is **not** extended for template tags
   // do something with the number
}
catch (err) {
  // handle the lack of a number gracefully
}

The latter of these approaches, requiring try..catch, is much less attractive than the graceful fallback to an easily detectable undefined value from the short-circuiting. It's less performant, and it's also more brittle, because there are various reasons that the exception can be thrown, so I'm probably going to have to do conditional logic on the err variable to check if it's related to the number template tag missing or something else.

The point, again, is that I and other users of TypL would like to be able to take advantage of ?.` short-circuting on these tag annotations, because the if..else handling is more graceful and friendly than the try..catch handling flavor.

Of course, there's no real code to point to doing this yet, since (1) this feature is only stage3 (2) the requested form is not supported (3) TypL is still under development. But if the requested form is added, I will add this support to TypL and then there will be real usages of the pattern.

fwiw the alternative would probably be closer to number && number`42` , since optionality isn’t about catching exceptions, it’s about safely navigating past null and undefined (number == null ? number : number`42` if you want to be pedantic or if the difference matters to your use case)

@ljharb

@ljharb

That's one way of doing it, but I would say it completely breaks the ergonomic essence of this tag acting like a value-site type annotation, so it isn't how I would want to do it, nor do I think anyone who I expect to use TypL.

But your point of optionality is valid with respect to a default using the new ?? instead of an if statement:

var x = number?.`${ someVal }` ?? 42;

In many cases, that sort of usage would probably be far preferable to either the try..catch, if..else, or just letting an error happen, approaches.

Other examples besides TypL... both Styled-Components and Lit-HTML use template tags. And the same "what if the tag function isn't present" scenario, along with a backup default value in that case, applies to them. Could be that the whole library didn't load, or could be that a custom style type being referenced that for some reason didn't get defined.

For example:

const Button = styled.Button?.`
     color: red;
  ` ?? defaultButton;

Here, if styled.Button is not present, the short-circuiting to undefined allows the ?? defaultButton fallback handling.

With the html tag from Lit-HTML:

const Button = html?.`<button> ... </button>` ?? defaultButton;

"Forgot to load the library" doesn't feel like a strong argument because in those cases number wouldn't be undefined, it would be undeclared, so doing:

number?.`42`

would be a ReferenceError (in strict mode). In order for this to be useful, the developer would have to:

Use ES6+ syntax (for template strings).
Execute their code in sloppy mode.
Expect that the library may not load in all cases and desire a fallback in that case.

This feels like a really narrow use case to me.

This feels like a really narrow use case to me.

Agreed. I think we're going to need a really strong usecase for the committee to agree to this, but even if we find one this should be done as a follow on proposal (the core ?. is important enough to ship it now).

(edit: removed comments)

I'm going to drop out of this thread because there doesn't appear to be anything further to discuss.

Now that we are at Stage 3, we can consider that the set of included operators is fixed. Optional template literal is not included, but the spec is forward compatible with an eventual future inclusion in case the need would be manifest.

Navigation Menu

Repository navigation

tagged template literals should be allowed (for completeness) #54

22 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

tagged template literals should be allowed (for completeness) #54

Description

Activity

ScottRudiger commented on Mar 12, 2018

claudepache commented on Mar 12, 2018

ScottRudiger commented on Mar 12, 2018

ScottRudiger commented on Mar 12, 2018

alangpierce commented on Mar 12, 2018

ScottRudiger commented on Mar 12, 2018

littledan commented on Mar 13, 2018

claudepache commented on Mar 14, 2018

claudepache commented on Mar 14, 2018

ljharb commented on Mar 14, 2018

ScottRudiger commented on Mar 14, 2018

claudepache commented on Mar 14, 2018

ScottRudiger commented on Mar 14, 2018

ljharb commented on Mar 14, 2018

claudepache commented on Mar 14, 2018

22 remaining items

claudepache commented on Jun 7, 2019

getify commented on Jun 7, 2019

hax commented on Jul 26, 2019

getify commented on Jul 26, 2019

getify commented on Jul 26, 2019

claudepache commented on Jul 26, 2019

getify commented on Jul 26, 2019

ljharb commented on Jul 26, 2019

getify commented on Jul 26, 2019

getify commented on Jul 26, 2019

mAAdhaTTah commented on Jul 26, 2019

jridgewell commented on Jul 26, 2019

getify commented on Jul 27, 2019

claudepache commented on Aug 21, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions