Summary
Add a macro concat_bytes!()
to join byte sequences onto an u8
array,
the same way concat!()
currently supports for str
literals.
Motivation
concat!()
is convenient and useful to create compile time str
literals
from str
, bool
, numeric and char
literals in the code. This RFC adds an
equivalent capability for [u8]
instead of str
.
Guide-level explanation
The concat_bytes!()
macro concatenates literals into a byte string literal
(an expression of the type &[u8; N]
). The following literal types are
supported as inputs:
-
byte string literals (
b"..."
) -
byte literals (
b'b'
) -
numeric array literals – if any literal is outside of
u8
range, it will cause a compile time error:error: cannot concatenate a non-`u8` literal in a byte string literal --> $FILE:XX:YY | XX | concat_bytes!([300, 1, 2, 256], b"val"); | ^^^ ^^^ this value is larger than `255` | | | this value is larger than `255`
For example, concat_bytes!(42, b"va", b'l', [1, 2])
evaluates to
[42, 118, 97, 108, 1, 2]
.
Drawbacks
None known.
Rationale and alternatives
concat!
could instead be changed to sometimes produce byte literals instead of
string literals, like a previous revision of this RFC proposed. This would make
it hard to ensure the right output type is produced – users would have to use
hacks like adding a dummy b""
argument to force a byte literal output.
An earlier version of this RFC proposed to support integer literals outside of
arrays, but that was rejected since it would make the output of
byte_concat!(123, b"\n")
inconsistent with the equivalent concat!
invocation.
Unresolved questions
- Should additional literal types be supported? Byte string literals are
basically the same thing as byte slice references, so it might make sense to
support those as well (support
&[0, 1, 2]
in addition to[0, 1, 2]
). - What to do with string and character literals? They could either be supported with their underlying UTF-8 representation being concatenated, or rejected.