You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Lift Template Literal Restriction on Backslashes #12700
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
letx=tag`\u{wat}`;
is now valid, whereas previously it would be considered an error.
As of this writing, the linked proposal is at Stage 3.
Notes
This restriction lift doesn't apply to untagged template strings. For example:
// All of these are still invalid.letbad=`bad escape sequence: \unicode`;letbracingOurselves= `\u{shouldntDoThis}`;let theWorst = `\xtremelybad`;
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:
functiontag(strs){console.log(strs[0]===undefined);console.log(strs.raw[0]==="\\unicode and \\u{55}");}
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!
Activity
clavecoder commentedon May 22, 2017
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 commentedon Apr 28, 2018
Interested in this😉
DanielRosenwasser commentedon Apr 28, 2018
Wenlu Wang (@Kingwl) In implementing it, or using it? 😃
Kingwl commentedon Apr 28, 2018
related #5291
should we re-implement EscapeSequence in the scanner ?
DanielRosenwasser commentedon Apr 28, 2018
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 commentedon Apr 28, 2018
By the way, template emit now uses a helper, so the proposed emit is a little different.
Kingwl commentedon Apr 29, 2018
Should the new grammar be always used or what options are needed?
more than 90 baseline changed
Kingwl commentedon Apr 29, 2018
Jake Ginnivan (@JakeGinnivan)
seems could fixed in this change
Kingwl commentedon Apr 30, 2018
how could i know that template is tagged in,scanner? i have no idea😓
DanielRosenwasser commentedon Apr 30, 2018
I think you'll have to actually add a rescan method on the scanner (e.g.
rescanTaggedTemplateHeador something).Kingwl commentedon May 1, 2018
ahhh,
reScanis work, but the error which first time scan are preserved,how could i remove those incorrect error