Tracking Issue for RFC2509: concat_bytes!() #87555
Comments
m-ou-se
added
T-libs-api
|
I'm working on an implementation at Smittyvb:concat_bytes. |
|
Implementation PR: #87599 |
|
Regarding the unresolved questions - can we reject regular string slices if we accept |
|
@Fishrock123 Macro arguments are not a constant evaluation context, so calls to For example, const fn add_one(x: u8) -> u8 { x + 1 }
macro_rules! demo {
($x:expr) => { let x = $x; }
}
trace_macros!(true);
demo!(add_one(2));gives the output The |
The tracking issue for this is rust-lang#87555.
…acrum Implement concat_bytes! This implements the unstable `concat_bytes!` macro, which has tracking issue rust-lang#87555. It can be used like: ```rust #![feature(concat_bytes)] fn main() { assert_eq!(concat_bytes!(), &[]); assert_eq!(concat_bytes!(b'A', b"BC", [68, b'E', 70]), b"ABCDEF"); } ``` If strings or characters are used where byte strings or byte characters are required, it suggests adding a `b` prefix. If a number is used outside of an array it suggests arrayifying it. If a boolean is used it suggests replacing it with the numeric value of that number. Doubly nested arrays of bytes are disallowed.
Contributes to rust-lang#87555.
Support [x; n] expressions in concat_bytes! Currently trying to use `concat_bytes!` with a repeating array value like `[42; 5]` results in an error: ``` error: expected a byte literal --> src/main.rs:3:27 | 3 | let x = concat_bytes!([3; 4]); | ^^^^^^ | = note: only byte literals (like `b"foo"`, `b's'`, and `[3, 4, 5]`) can be passed to `concat_bytes!()` ``` This makes it so repeating array syntax can be used the same way normal arrays can be. The RFC doesn't explicitly mention repeat expressions, but it seems reasonable to allow them as well, since normal arrays are allowed. It is possible to make the compiler get stuck compiling forever with `concat_bytes!([3; 999999999])`, but I don't think that's much of an issue since you can do that already with `const X: [u8; 999999999] = [3; 999999999];`. Contributes to rust-lang#87555.
Support [x; n] expressions in concat_bytes! Currently trying to use `concat_bytes!` with a repeating array value like `[42; 5]` results in an error: ``` error: expected a byte literal --> src/main.rs:3:27 | 3 | let x = concat_bytes!([3; 4]); | ^^^^^^ | = note: only byte literals (like `b"foo"`, `b's'`, and `[3, 4, 5]`) can be passed to `concat_bytes!()` ``` This makes it so repeating array syntax can be used the same way normal arrays can be. The RFC doesn't explicitly mention repeat expressions, but it seems reasonable to allow them as well, since normal arrays are allowed. It is possible to make the compiler get stuck compiling forever with `concat_bytes!([3; 999999999])`, but I don't think that's much of an issue since you can do that already with `const X: [u8; 999999999] = [3; 999999999];`. Contributes to rust-lang#87555.
|
@m-ou-se should the implementation box be checked off now? It seems the PR to implement it was merged. |
|
Was FCP started? |
|
👋 , just ran into this trying to use it on a stable-codebase I'm working on. I'm curious is there any blockers/open-questions with this issue that aren't reflected here. Could we start stabilizing this? |
|
Hi. I have just implemented this in my library: |
|
Is this feature still unstable? |
|
I just ended up needing this macro for the first time. I needed to include a certificate in my binary. And my dependency's static CERTIFICATE: X509 = X509::pem_until_nul(concat_bytes!(
include_bytes!("../certs/server_certificate.pem"),
b"\0"
));I switched over to const_str::concat_bytes for now, since it's stable. But I personally think the std macro should adopt any advantages that it has and stabilize it. This type of macro belongs in |
|
I think the only issues that need to be resolved before stabilization are:
I think the status quo is fine. Does anyone think |
|
Not that I currently need it, but supporting const evaluation of non-literals seem very handy. Not being able to currently do I have two questions:
|
|
Are the remaining questions irreversible decisions? For example, if If the answer is "yes" then I think it clearly should be stabilized. Combining Also, I've been using this implementation of macro_rules! concat_bytes {
($( $chunk:expr ),+ $( , )?) => {{
struct Chunk<T>(T);
#[allow(dead_code)]
impl<const N: usize> Chunk<[u8; N]> {
const fn get(&self) -> &[u8] { &self.0 }
}
#[allow(dead_code)]
impl<const N: usize> Chunk<&[u8; N]> {
const fn get(&self) -> &[u8] { self.0 }
}
#[allow(dead_code)]
impl Chunk<&[u8]> {
const fn get(&self) -> &[u8] { self.0 }
}
const fn bytes_len(chunks: &[&[u8]]) -> usize {
let mut len = 0;
let mut ii = 0;
while ii < chunks.len() {
len += chunks[ii].len();
ii += 1;
}
len
}
const fn chunks_concat<const N: usize>(chunks: &[&[u8]]) -> [u8; N] {
let mut buf = [0u8; N];
let mut ii = 0;
let mut buf_idx = 0;
while ii < chunks.len() {
let mut jj = 0;
while jj < chunks[ii].len() {
buf[buf_idx] = chunks[ii][jj];
jj += 1;
buf_idx += 1;
}
ii += 1;
}
buf
}
const CHUNKS: &[&[u8]] = &[$( Chunk($chunk).get() ),+];
const BYTES_LEN: usize = bytes_len(CHUNKS);
const BYTES: [u8; BYTES_LEN] = chunks_concat(CHUNKS);
BYTES
}};
} |
That feels like something better for an |
Feature gate:
#![feature(concat_bytes)]This is a tracking issue for rust-lang/rfcs#2509
Public API
Steps / History
concat_bytes!()to join[u8]and bytestranalogous toconcat!forstrrfcs#2509Unresolved Questions
&[0, 1, 2]in addition to[0, 1, 2]).The text was updated successfully, but these errors were encountered: