RFC: a byte string concatenation macro

[mzabaluev]

The removed bytes! macro is still needed and should be brought back, updated to accept byte string literals.

Rendered

[netvl]

Big +1. I used this macro in my networking programs extensively and I never saw the reason to remove it. It does a different thing than byte literals do. Byte literals are good when you have ASCII data; when you want to work with numbers instead of characters, it becomes very unwieldy.

[SimonSapin]

when you want to work with numbers instead of characters, it becomes very unwieldy.

If you have only numbers, you can use the array syntax: let foo: &[u8] = &[0x66, 0x6F, 0x6F]

[netvl]

@SimonSapin, I should have expressed myself better. Of course, I meant the situation when numbers are mixed with characters.

[alexcrichton]

It seems somewhat inconsistent to me for string concatenation to be called concat! while byte concatenation is called bytes!, and we may want to consider more symmetric names for the two.

[mzabaluev]

@alexcrichton Yeah, there is a note about possibly naming it concat_bytes! in the PR.

[brson]

What are the workarounds for the lack of this functionality?

[mzabaluev]

What are the workarounds for the lack of this functionality?

None that I know to work in macros.

[SimonSapin]

@brson This seems like a fair description. bytes! seemed redundant with byte string literals as "some way to get &[u8] from ASCII text", but talking about concatenation is more interesting. And since we already have concat! on Unicode strings, I don’t see a justification to reject its bytes equivalent.

So I’d be fine with:

• Rename concat! to concat_str!
• Add concat_bytes!

[kjpgit]

I would like a way to have a long (>100) byte string literal but keep everything under 80 columns and make it multi line in source code. I think this does that, so +1

[lfairy]

@SimonSapin As a bonus, that'll be consistent with include_str! and include_bytes!.

[aturon]

ping @brson

[brson]

I'm afraid that at this time we just don't want to do this. It's niche functionality, and it can be done in a plugin. Let's table this and see if it comes back to bite us again. Thanks, and sorry for dragging this out.

[SimonSapin]

I would like a way to have a long (>100) byte string literal but keep everything under 80 columns and make it multi line in source code.

Like in Unicode string, a newline can be escaped with \ in byte strings:

assert_eq!(b"foo", b"fo\
                      o");

[pythonesque]

I do not understand why this was removed. It can be done in a plugin, sure, but Rust 1.0 doesn't support plugins. And it's not niche functionality when you're trying to avoid copies for binary protocols, as is often the case in networking.

[casey]

May I propose that this be re-opend? I needed this today, and was surprised that it doesn't exist. It seems that if concat! exists, there is a good argument that concat_bytes! should also exist.

[nox]

There is no way to do a macro for NUL-terminated byte sequences without a concat_bytes! macro. Many FFI things needs static NUL-terminated ASCII strings and I don't think this can be considered a niche feature for that reason.

Procedural macros for arbitrary expressions are far from being stable, right?

[Ferdi265]

Stumbled upon this today. Compile-time concatenating byte literals or byte arrays should really be a thing

[danielhenrymantilla]

I have come up with a solution that works in stable rust: https://docs.rs/byte-strings/0.1.0/byte_strings/macro.c_str.html