Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove \xXX char escapes from the language #312

Closed
rust-highfive opened this issue Sep 24, 2014 · 3 comments · Fixed by #326
Closed

Remove \xXX char escapes from the language #312

rust-highfive opened this issue Sep 24, 2014 · 3 comments · Fixed by #326

Comments

@rust-highfive
Copy link

Issue by Valloric
Saturday Mar 08, 2014 at 21:19 GMT

For earlier discussion, see rust-lang/rust#12769

This issue was labelled with: B-RFC in the Rust repository


\xXX is very misleading in Rust since it actually works exactly like \u00XX instead of the way it works in C, C++ and other languages. Example:

// this FAILS because left is [195, 191]
assert_eq!( bytes!( "\xFF"), bytes!( 255 ) ); 
// this SUCCEEDS
assert_eq!( bytes!( "\xFF"), bytes!( "\u00FF" ) );  

I understand the reasoning behind this (Rust strings are always UTF-8), but then \xXX shouldn't exist in the language. It brings nothing but confusion and it's functionality as implemented is the same as \u00XX.

@Ryman
Copy link

Ryman commented Sep 26, 2014

Using the modern syntax b"\xFF" this now has expected behavior. See: http://is.gd/3J0ysQ

@pnkfelix
Copy link
Member

I think the original discussion thread is relevant here.

In particular, I think the real point is that this RFC is literally talking about char escapes. Yes, its example is then converting its input strings to byte arrays, and yes that is outdated syntax, but we still have support for \xXX in a string literal context, and it is probably still confusing. (Playpen illustration: http://is.gd/o7O43q )

So we should either remove support for \xXX from our string literals, or we should restrict it to only work for inputs in the ASCII range, as suggested a [1] few [2] times [3].

I'm going to write up an RFC for this right now, because it seems like a non-controversial change that would still have backwards-compatibility implications if we do not get it in for 1.0.

@Ryman
Copy link

Ryman commented Sep 26, 2014

@pnkfelix Ah yes, I'd overlooked the main argument. (Really shouldn't have commented at 4am :D)

wycats pushed a commit to wycats/rust-rfcs that referenced this issue Mar 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants