consider including byte literals (alternative to integer literals for [u8] and u8)

[thestinger]

It would be nice if b"foo" could be used instead of str::as_bytes_slice("foo"), and especially ~b"bar" instead of vec::from_slice(str::as_bytes_slice("bar")). Python uses this convention and only allows ASCII inside the byte string literals (along with byte escape codes). I don't really think it's necessary to forbid Unicode though - Python does that to make a very clear distinction between bytes and strings.

There could also be a byte version of a char literal, allowing any ASCII character (b'\n') - a 55u8 literal removes the need for escape codes there.

[catamorphism]

This could be implemented as a syntax extension, maybe? But it would have to be b!("foo") or ~b("bar").

[thestinger]

@catamorphism: that's a good idea, but do you think that could work for an &static/str equivalent? It can definitely work for the single byte literal form though (just verify that it's in the range, and convert).

[jdm]

I believe that allowing byte literals like this would make using some C APIs like Spidermonkey significantly easier, since things like JSClass instances could finally just be constant data.

[graydon]

A syntax extension would be able to produce &static/[u8], sure. It'd just be lowering bytes!("abc") to &[97_u8, 98_u8, 99_u8]

[Aatch]

Nominating for well-covered

[graydon]

accepted for feature complete

[sanxiyn]

@graydon, bytes! is now done, how should byte! (or b!?) work? byte!('a') expands to 97u8?

[emberian]

afaict he means byte!/b! is the same is what you added for bytes!

[sanxiyn]

Now we have [u8] literal, but no u8 literal yet.

[emberian]

4u8, 0x3Au8?

[sanxiyn]

Well, if bytes!("a") is better than &[97u8], byte!('a') could be better than 97u8.

[emberian]

There's also 'a' as u8, which is shorter than byte!('a').

[sanxiyn]

One consideration is that since #6417 'a' as u8 can't be used as a pattern, while 97u8 (and a macro that expands to it) can.

[emberian]

Ok, good reason :)

[huonw]

@sanxiyn I don't think macros parse as patterns yet:

rusti> match 1 { some_macro!() => 1 }
<anon>:2:21: 2:22 error: expected `=>` but found `!`
<anon>:2  match 1 { some_macro!() => 1 } 
                              ^

[bstrie]

Syntax extensions can inspect types, right? Could bytes!() simply be made smart enough to generate [u8] when given a string and u8 when given a char? Is this way too magical? It just seems a tad redundant to have two syntax extensions where one of them is just sugar for 97u8.

[huonw]

Syntax extensions can't inspect types properly, but they can tell whether a given literal is a char or string. (Personally I think that would be a little bit magical, since bytes!('a', 'b') would be a [u8] but bytes!('a') would be u8: could lead to head scratching.)

[chris-morgan]

Here are the basics of what I want. I've been needing to deal with bytes a lot in rust-http, and there will be many other similar projects that do have to deal with bytes a lot.

Firstly: b'x', equivalent to ('x' as u8), but a literal able to be used in patterns and such.

Secondly: b"x", equivalent to &[b'x', b'y'].

Thirdly: sigil support for the two above which removes the implied &, as with "x" being &'static str and ~"x" being ~str. This is something that cannot presently be done.

[lilyball]

I'm a fan of 'a'u8 syntax (hence #9302) for char literals, which has the benefit of allowing other types too, e.g. 'a'u32 if you need a u32 instead of a u8.

[thestinger]

@kballard: the problem I have with that syntax is it not being clear what the corresponding (if any) string literals would be, like "foo"u32 or "foo"u64

[lilyball]

@thestinger String literals like that don't make sense. The only sensible string literal is the byte literal, and I don't think there's any need to use the same syntax for string-literal-as-[u8] vs char-literal-as-specified-integral-type, as they're distinct concepts.

[thestinger]

So b"foo" for &'static [u8] and 'a'u8, 'a'i64, etc. as new ways of declaring integers. I guess it would just fail to compile if the code point was out-of-range for the type.

[lilyball]

@thestinger Yeah, that's what I'm thinking is the most sensible.

[thestinger]

Added back the RFC tag. It's not clear that bytes!() is satisfactory (it may be once syntax extensions work in more places) or what we want as the syntax (or syntax extensions).

[SimonSapin]

As @huonw said earlier, I’d like something that is usable in patterns. This is currently invalid:

match c { 'a' as u8 .. 'z' as u8 => /* … */ }

[SimonSapin]

+1 to @chris-morgan’s proposal: #4334 (comment)

[pnkfelix]

P-low, not 1.0 blocker.

[SimonSapin]

This should be a new-style RFC.

[huonw]

Thanks @SimonSapin (rust-lang/rfcs#69).