在ECMA-262严格模式下，是否允许在字符串中使用\\\\后跟十进制数字？

Question

According to the ECMA-262 specification (6th edition) in strict mode in single or double quoted strings after '\\' it is possible to have EscapeSequence or LineTerminatorSequence, and EscapeSequence must be one of the following: CharacterEscapeSequence, 0 [lookahead ∉ DecimalDigit], HexEscapeSequence, UnicodeEscapeSequence (see 11.8.4).

Does it mean that it is completely incorrect to have any DecimalDigit after '\\0' at all?

I understand that it is done that way to avoid confusion with LegacyOctalEscapeSequence (from B.1.2), but it required only octal digits being placed after the first '\\0', and V8 engine seems to support this in that way (see below).

After checking up with the implementations it turns out that V8 engine allows having '\\0' followed only by DecimalDigit which is not an OctalDigit. In that case, it resolves it into the string with the string values of 0 at first position and then code point value of next digit as a SourceCharacter. When it is given an OctalDigit after the '\\0', it throws a SyntaxError with message "Octal escape sequences are not allowed in strict mode.", which is a bit misleading. Chakra and SpiderMonkey seem to throw SyntaxError on any DecimalDigit after the '\\0', but with the similar message about octal escape sequences, which looks especially strange in some cases (with '8' or '9' after the '\\0', which couldn't be an octal escape sequence outside of strict mode).

So, my question is what is the correct interpretation of the specification?

Answer 1

"0 [lookahead ∉ DecimalDigit]" sounds pretty unambiguous to me: no decimal digit is allowed after \\0 .

Which means the fact that V8 allows "\\08" and "\\09" in strict mode is a bug. Would you please file a bug at https://bugs.chromium.org/p/v8/ ?

Interestingly, test262 does not seem to cover this case at all...

Somewhat related: all browsers accept "\\8" and "\\9" in strict mode, which according to the spec should throw a SyntaxError. There's a thread on esdiscuss.org indicating that this spec violation is (or at least used to be) required for web compatibility though: when existing websites depend on non-spec-compliant behavior, then browsers usually can't just update their behavior to be spec-compliant, because doing so would break such websites, and having websites work correctly is more important for users (and, hence, browser developers) than being spec-compliant.