This was removed on purpose, the x escape is incorrect for chars. For example \xff is not a valid unicode codepoint.

Same goes with octal. This was removed explicitly by me some months ago. Let's not add it back.

related to #2886

Why?

This is also about character escape codes and you suggested to maybe remove \x.. escapes from strings at some point.
When (and if) this is removed, there would be no difference between "\x64" and '\x64' because both were invalid.
I thought it might be worth to mention this here.

@straight-shoota Thank you.

@asterite I can't understand "for example \xff is not a valid unicode codepoint" because U+00FF points 'LATIN SMALL LETTER Y WITH DIAERESIS' and I consider \xff means it. But the purpose makes me sense and I think we should remove octal and hex style escape sequence from string literal after #2886 resolved.

In a String, "\xff" will generate a string with one byte whose value is 255. That's not a valid UTF-8 string but it's valid as just a sequence of bytes (there's a big discussion on whether this should be allowed or not, or maybe just allowed in Slice(UInt8) literals, but that doesn't exist yet).

But a Char is an Int32 that holds an UTF-8 codepoint. A byte value and a codepoint are different things. \xff means "a byte with value 255", but in the comment above it means "a char with codepoint 255", which is 'ÿ'. But a String written as "\xff" is not the same as "ÿ". And "ÿ" in bytes is [195, 191].

It's a bit confusing, and in the original implementation '\xff' did generate 'ÿ', but that's wrong.

Another way to show it. Using this PR, do this:

"\xFF"[0] == '\xFF'

You will see that is false, which is quite unexpected.

@asterite Good example!