Triple tick syntax backwards compatibility

[bathos]

The Q&A section has an "Is this backwards compatible?" section which acknowledges that the proposed syntax is already syntactically valid with a different meaning, but concludes that it's nonetheless a backwards-compatible change because it would always result in a runtime error.

Obviously, none of that will currently work at runtime, because an empty string is not a function. So no functioning code should be affected by this change.

This seems to assume that the result of a tagged template expression is always a string, which isn't the case. The expression can return anything, including another template tag function.

let t = () => t;
t``` ```; // t

The proposal itself would be very useful imo, but will likely need to rethink the syntax; given chaining tags like this has been valid JS for five years, altering its meaning now isn't safe (even in the unlikely event that no code like this is found in the wild, since it creates a mechanism to craft code that successfully evaluates with different meanings depending on the agent).

[bakkot]

even in the unlikely event that no code like this is found in the wild

Here is some code like this in the wild.

[bathos]

@bakkot I can’t decide if I love this or hate it haha. Throw in a custom toString and the intern-trolling potential goes through the roof.

[jridgewell]

Ah, I hadn't considered the tag continually returning a function. I think when we reasoned this, we were just looking at the untagged form (which is definitely a runtime error).

I still think the compat risk here is minimal, but it's not 0% anymore.

[mmkal]

Great find @bakkot - and the gist isn't even that contrived.

Jsonnet (mentioned in the readme) uses |||, and is close to valid ecmascript, so maybe that would be a better strawperson syntax?

[ExE-Boss]

What about using """ instead?

[andyearnshaw]

What about using """ instead?

I think both """ and ''' are problematic because they would introduce confusing differences from their standard string delimiter counterparts. For example, """...""" would allow interpolation but "..." doesn't, tag"""...""" would work but tag"..." doesn't.

I think the ship has sailed on new delimiters for strings. I'd considered proposing ``` a couple of years ago but I'd not had much luck raising the prospects of dedented strings back before template strings were finalised. There were some interesting suggestions in that original thread, maybe it's worth looking at these ideas again?

Particularly, someone proposed a keyword after the delimiter:

    var a = `This is a template string.
             Even though each line is indented to keep the
             code neat and tidy, the white space used to indent
             is not in the resulting string` trim-indent;

Not sure how feasible this is as you'd probably want the parser to know up front whether the indent should be dropped. There's also no existing precedent for this kind of directive in the language or similar languages (that I can think of).

[rbuckton]

Another option might be to use @`...`:

const x = @`
           Line 1
           Line 2
`;

const y = foo@`
           Line 1
           Line 2
`;

Allow any number of leading ` characters and end on an exact match of the same number of ` characters to avoid escaping (similar to markdown).

Currently @ is only really being considered for decorators, though there was interest in @ for literal suffixes (like 123@px), but in neither case would a template literal trailing the @ make sense and there's enough time for those proposals to add a specific syntax carve-out to avoid ambiguity.

[sken130]

If we introduce new syntax, we should make it worthwhile to include more features and solve as many problems as possible, otherwise the features proposed too late will become breaking changes in the future.

Here is my proposal of adding raw string literal to ECMAScript/JavaScript to solve multiple problems together:

• indentation/dedentation
• string interpolation
• multi-line string
• containing arbitrary text without escaping

https://es.discourse.group/t/raw-string-literals-that-can-contain-any-arbitrary-text-without-the-need-for-special-escape-sequences/1757/3

(Mentioned in #40 as well)