Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Lift Template Literal Restriction on Backslashes #12700

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
DanielRosenwasser opened this issue Dec 6, 2016 · 11 comments · Fixed by #23801 or #51837
Closed

Lift Template Literal Restriction on Backslashes #12700

DanielRosenwasser opened this issue Dec 6, 2016 · 11 comments · Fixed by #23801 or #51837
Labels
Bug A bug in TypeScript ES Next New featurers for ECMAScript (a.k.a. ESNext) Help Wanted You can do this
Milestone
Backlog

Comments

@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Dec 6, 2016 •
edited
Loading

Overview

Everyone loves LATEX so ESNext will likely allow tagged template strings to contain backslashes on any sequence - even ones that look like they might contain an invalid Unicode escapes.

In other words, something like

let x = tag `\u{wat}`;

is now valid, whereas previously it would be considered an error.

Reference: https://tc39.github.io/proposal-template-literal-revision/

As of this writing, the linked proposal is at Stage 3.

Notes

  1. This restriction lift doesn't apply to untagged template strings. For example:

    // All of these are still invalid.
let bad = `bad escape sequence: \unicode`;
let bracingOurselves = `\u{shouldntDoThis}`;
let theWorst = `\xtremely bad`;

  2. Because there is no appropriate representation for a "cooked" string that contains one of these escapes, the returned value at a position on the top-level array will be undefined, but the raw representation will be available. For example:

    function tag(strs) {
  console.log(strs[0] === undefined);
  console.log(strs.raw[0] === "\\unicode and \\u{55}");
}

// Prints 'true' twice.
tag\unicode and \u{55}

Proposed Emit

Input:

let x = tag `\u{hello} ${ 100 } \xtraordinary ${ 200 } wonderful ${ 300 } \uworld`;

Output:

var x = (
    _a = [undefined, undefined, " wonderful ", undefined],
    _a.raw = ["\\u{hello} ", " \\xtraordinary ", " wonderful ", " \\uworld"],
    tag(_a, 100, 200, 300)
);
@DanielRosenwasser DanielRosenwasser added the ES Next New featurers for ECMAScript (a.k.a. ESNext) label Dec 6, 2016
@mhegazy mhegazy added the Bug A bug in TypeScript label Dec 8, 2016
@mhegazy mhegazy added this to the TypeScript 2.2 milestone Dec 8, 2016
@mhegazy mhegazy modified the milestones: Community, TypeScript 2.2 Dec 30, 2016
@mhegazy mhegazy added the Help Wanted You can do this label Dec 30, 2016
@clavecoder
Copy link

This was bumped to stage 4 in 2017-03. It is slated for inclusion in ES2018

https://github.com/tc39/proposals/blob/master/finished-proposals.md

@Kingwl
Copy link
Contributor

Kingwl commented Apr 28, 2018

Interested in this😉

@DanielRosenwasser
Copy link
Member Author

DanielRosenwasser commented Apr 28, 2018 •
edited
Loading

@Kingwl In implementing it, or using it? 😃

@Kingwl
Copy link
Contributor

Kingwl commented Apr 28, 2018

related #5291
should we re-implement EscapeSequence in the scanner ?

@DanielRosenwasser
Copy link
Member Author

should we re-implement EscapeSequence in the scanner ?

I don't know why that'd be necessary, I think you just need to potentially thread through some extra context when you're scanning these things (which is what the ECMAScript spec does in the grammar now). But I might've missed something, so feel free to send the PR and we can iterate on it!

@DanielRosenwasser
Copy link
Member Author

By the way, template emit now uses a helper, so the proposed emit is a little different.

@Kingwl
Copy link
Contributor

Kingwl commented Apr 29, 2018

Should the new grammar be always used or what options are needed?
more than 90 baseline changed

@Kingwl
Copy link
Contributor

Kingwl commented Apr 29, 2018

@JakeGinnivan

We have just hit this issue upgrading from 2.4.1 to 2.6.1.

glamorous.h3({
'&::after': {
content: "\\00BB"
}
})
Before it output chevrons, after the upgrade it output x000BB.

seems could fixed in this change

@Kingwl
Copy link
Contributor

Kingwl commented Apr 30, 2018

how could i know that template is tagged in,scanner？ i have no idea😓

@DanielRosenwasser
Copy link
Member Author

I think you'll have to actually add a rescan method on the scanner (e.g. rescanTaggedTemplateHead or something).

@Kingwl
Copy link
Contributor

Kingwl commented May 1, 2018 •
edited
Loading

ahhh, reScan is work, but the error which first time scan are preserved,
how could i remove those incorrect error

@Kingwl Kingwl mentioned this issue May 1, 2018
Merged
@RyanCavanaugh RyanCavanaugh modified the milestones: Community, Backlog Mar 7, 2019
@lydell lydell mentioned this issue Jun 8, 2019
Closed
@rbuckton rbuckton mentioned this issue May 8, 2020
Closed
@DanielRosenwasser DanielRosenwasser mentioned this issue Oct 7, 2021
Open
@graphemecluster graphemecluster mentioned this issue Dec 9, 2022
Merged
@engelsdamien engelsdamien mentioned this issue Aug 14, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug A bug in TypeScript ES Next New featurers for ECMAScript (a.k.a. ESNext) Help Wanted You can do this
Projects
None yet
Milestone
Backlog
5 participants
@DanielRosenwasser @clavecoder @RyanCavanaugh @Kingwl @mhegazy