Tracking issue for RFC 446 - ES6-style unicode escapes

[pnkfelix]

Remove \u203D and \U0001F4A9 unicode string escapes, and add ECMAScript 6-style \u{1F4A9} escapes instead.

Text: https://github.com/rust-lang/rfcs/blob/master/text/0446-es6-unicode-escapes.md
RFC PR: rust-lang/rfcs#446

Migration strategy: https://github.com/rust-lang/rfcs/blob/master/text/0446-es6-unicode-escapes.md#migration-strategy

[pnkfelix]

Note that stage 1 and the foundation for stage 2 in the migration strategy have been added by PR #19480

[emk]

I know this is probably on your to-do list already, but I found an interesting corner-case in syntax::print, and traced it back to std::char::Char::escape_unicode: #19811

[aochagavia]

Though not mentioned in the RFC, we still have \x.. to escape hexadecimal characters. Is this explicitly intended or should it also be removed?

[steveklabnik]

Hexidecimal doesn't suffer the same issues, because the full range is expressible, right?

[aochagavia]

It seems weird to me that you can do this: assert_eq!('\u{7f}', '\x7f'). But maybe it is just me.

I thought that \x should be deprecated as it is just a limited version of \u{...}.

[aochagavia]

cc @SimonSapin what do you think?

[SimonSapin]

I suggest leaving \xHH unchanged.

The reasoning behind the {} delimiters in \u{1F4A9} is to allow a variable number of digits, without initial zeros. Unicode goes up to U+10FFFF with 6 digits, but the majority of assigned code points still only needs 4 significant digits or less.

\xHH is fixed to two digits, but the \x00 to \x0F range is all control characters, most of which are very rarely used. The less rare ones, \x00 (nul), \x09 (tab), \x0A (newline), and \x0D (carriage return) all have shorter syntax already: \0, \t, \n, and \r, respectively. So there is no point in having \x{HH} and \x{H}.

[SimonSapin]

Oh, looks like I completely misread you, sorry. Yes, removing \xHH entirely when the replacement was \u00HH was annoying, but now it might not be as bad. I don’t mind either way, but it’d probably have to be a separate RFC. See rust-lang/rfcs#326 for prior discussion, including a decision not to remove it. (But that was before \u{H+})

[genbattle]

I have opened a PR here to update the documentation in relation to this change.

[alexcrichton]

This has been completed.