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').