Report "\8" and "\9" in no-octal-escape

What rule do you want to change?

no-octal-escape

Does this change cause the rule to produce more or fewer warnings?

more

How will the change be implemented? (New option, new default behavior, etc.)?

new default behavior

Please provide some example code that this change will affect:

"\8"

"foo\9bar"

What does the rule currently do for this code?

no errors

What will the rule do after it’s changed?

errors

Are you willing to submit a pull request to implement this change?

Yes.

\8 and \9 used to be invalid (unspecified) escape sequences in string literals. But, they were not not explicitly disallowed language extensions, and all engines used to allow "\8" and "\9", treating them as just "8" and "9" (i.e., as useless escapes).

Now, as of tc39/ecma262#2054, they are defined in Annex B as NonOctalDecimalEscapeSequence:

NonOctalDecimalEscapeSequence :: one of 89

and thus required in browsers, but only in non-strict mode. They are now explicitly disallowed in strict mode.

Although only recently added to the spec, the spec treats them as a legacy feature and in the same context as LegacyOctalEscapeSequence, so I think they should be reported by no-octal-escape.

Questions:

• no-octal-escape or no-useless-escape? I think no-octal-escape, but there are arguments for no-useless-escape, too.
• Can we make this change in a minor version?

[mdjermanovic]

no-nonoctal-escapes might sound like it would disallow all escapes that aren’t octal, including hexadecimal and unicode escape sequences.

Maybe no-nonoctal-decimal-escape? That would fully match the name from the specification.

[mdjermanovic]

Closing this in favor of #13765