Tracking Issue for RFC2509: concat_bytes!()

[m-ou-se]

Feature gate: #![feature(concat_bytes)]

This is a tracking issue for rust-lang/rfcs#2509

Public API

#[macro_export]
macro_rules! concat_bytes { .. }

Steps / History

• RFC: RFC: Introduce concat_bytes!() to join [u8] and byte str analogous to concat! for str rfcs#2509
• Implementation: Implement concat_bytes! #87599
• Final comment period (FCP)
• Stabilization PR

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.

[syvb]

I'm working on an implementation at Smittyvb:concat_bytes.

[syvb]

Implementation PR: #87599

[Fishrock123]

Regarding the unresolved questions - can we reject regular string slices if we accept &[] since str::as_bytes() is const?

[syvb]

@Fishrock123 Macro arguments are not a constant evaluation context, so calls to const fns in macros result in the tokens representing the function call getting passed to the macro, not the result of evaluating the function call.

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

note: trace_macro
 --> src/main.rs:8:1
  |
8 | demo!(add_one(2));
  | ^^^^^^^^^^^^^^^^^^
  |
  = note: expanding `demo! { add_one(2) }`
  = note: to `let x = add_one(2) ;`

The add_one(2) call never gets expanded to 3 (although LLVM can optimise that) , since it's not used in a constant evaluation context. It is treated no different then any other function.