RFC: ES6-style unicode string escaping.

[SimonSapin]

Rendered.

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: #446

[edef1c]

👍
This also increases readability — picking out a \uabcd in a long string of text is a lot harder than picking out \u{abcd}.

[emberian]

👍 as well.

[blaenk]

Yeah this is nice.

[reem]

+1 from me too. Definitely an improvement.

[pnkfelix]

One drawback not mentioned in RFC: format! templates that need Unicode escapes are forced to become uglier. (This need not be the case if we adopt the alternative of keeping both the old and new syntaxes)

[pnkfelix]

(Well, what I said isn't actually quite right, since the Unicode escape is probably handled at an earlier lexical level and thus would not be seen by the fmt code)

[SimonSapin]

@pnkfelix I don’t understand how format! templates are different from any string. Can you expand / give an example?

[alexcrichton]

I think @pnkfelix may be referring to something such as:

format!("{foo} \u{AF} {bar}", foo = "", bar = "")

In this case the braces around AF are lexed in the Rust parser as a unicode escape, while the braces around foo and bar are just normal parts of the string which are then interpreted as placeholders by the formatting string syntax.

[SimonSapin]

Oh, I see. That’s a good point, I’ve added it to Drawbacks.

[Gankra]

Is it possible to just use parens or some other delimiter?

[ftxqxd]

👍; this makes Unicode escapes much clearer and more obvious. It should be noted that using {} in escapes is not unique to ES6. Python, Perl, and probably many other languages have \N{foo bar} escapes, where foo bar is the name of any Unicode character. Perhaps Rust should have these, too: \N{no-break space} is much clearer and more self-explanatory than \u{a0}.

[mdinger]

As best I can tell, the aliases used with Python Unicode escape sequences are documented here

[huonw]

@P1start (FWIW, I actually have a macro lib that offers that.)

[SimonSapin]

@gankro, it would be possible, but we would lose the benefit of the ES6 precedent.

@P1start, interesting. "\N{foo}" currently causes a unknown character escape: N error, so adding named escapes later would be backward-compatible.

[pnkfelix]

we decided in the meeting today to merge this. However, we also want to revise the RFC language to ensure up front that we will land this in a manner such that there would exist a window of time where the old syntax is supported; i.e.: First add the new syntax as a feature, convert our code to use it, let that settle, and then remove the old syntax.

(Part of the reason we want to follow the above procedure is that we do not want to block 1.0 on this feature; making sure we remove the old syntax last, potentially in a separate beta cycle, should help mitigate that risk.)

@SimonSapin would you be up for revising the text to accommodate the above goal, or would you like me to do it on your behalf?

[SimonSapin]

@pnkfelix Please do the revising, as I’m not sure of the details of the language you have in mind.

Should usage of the old syntax give a warning, after the new one is added?

[pnkfelix]

@SimonSapin i suspect warning would be best.

[SimonSapin]

@pnkfelix The first part of this has landed: rust-lang/rust#19480 Should this be merged despite the "deployment plan" not being in the text?

[pnkfelix]

@SimonSapin ah sorry, I will try to merge pronto.