Rust has some great little magic built-in macros that you can use. A particularly-helpful one for building up paths and other text at compile-time is concat!. This takes two strings and returns the concatenation of them:
```rust const HELLO_WORLD: &str = concat!("Hello", ", ", "world!");
asserteq!(HELLOWORLD, "Hello, world!"); ```
This is nice, but it falls apart pretty quickly. You can use concat! on the strings returned from magic macros like env! and include_str! but you can't use it on constants:
rust
const GREETING: &str = "Hello";
const PLACE: &str = "world";
const HELLO_WORLD: &str = concat!(GREETING, ", ", PLACE, "!");
This produces the error:
``` error: expected a literal --> src/main.rs:3:35 | 3 | const HELLO_WORLD: &str = concat!(GREETING, ", ", PLACE, "!"); | ^^^^^^^^
error: expected a literal --> src/main.rs:3:51 | 3 | const HELLO_WORLD: &str = concat!(GREETING, ", ", PLACE, "!"); | ^^^^^ ```
Well with const_concat! you can! It works just like the concat! macro:
```rust
extern crate const_concat;
const GREETING: &str = "Hello"; const PLACE: &str = "world"; const HELLOWORLD: &str = constconcat!(GREETING, ", ", PLACE, "!");
asserteq!(HELLOWORLD, "Hello, world!"); ```
All this, and it's implemented entirely without hooking into the compiler. So how does it work? Through dark, evil magicks. Firstly, why can't this just work the same as runtime string concatenation? Well, runtime string concatenation allocates a new String, but allocation isn't possible at compile-time - we have to do everything on the stack. Also, we can't do iteration at compile-time so there's no way to copy the characters from the source strings to the destination string. Let's look at the implementation. The "workhorse" of this macro is the concat function:
```rust
pub const unsafe fn concat
let arr: Both<First, Second> =
Both(*transmute::<_, &First>(a), *transmute::<_, &Second>(b));
transmute(arr)
} ```
So what we do is convert both the (arbitrarily-sized) input arrays to pointers to constant-size arrays, then dereference them. This is wildly unsafe - there's nothing saying that a.len() is the same as the length of the First type parameter. We put them next to one another in a #[repr(C)] tuple struct - this essentially concatenates them together in memory. Finally, we transmute it to the Out type parameter. If First is [u8; N0] and Second is [u8; N1] then Out should be [u8; N0 + N1]. Why not just use a trait with associated constants? Well, here's an example of what that would look like:
```rust trait ConcatHack { const ALEN: usize; const BLEN: usize; }
pub const unsafe fn concat
let arr: Both<First, Second> =
Both(*transmute::<_, &[u8; C::A_LEN]>(a), *transmute::<_, &[u8; C::B_LEN]>(b));
transmute(arr)
} ```
This doesn't work though, because type parameters are not respected when calculating fixed-size array lengths. So instead we use individual type parameters for each constant-size array.
Wait, though, if you look at the documentation for std::mem::tranmute at the time of writing it's not a const fn. What's going on here then? Well, I wrote my own transmute:
```rust
pub const unsafe fn transmute
Transmute { from }.to
} ```
This is allowed in a const fn where std::mem::transmute is not. Finally, let's look at the macro itself:
```rust
macrorules! constconcat { ($a:expr, $b:expr) => {{ let bytes: &'static [u8] = unsafe { &$crate::concat::< [u8; $a.len()], [u8; $b.len()], [u8; $a.len() + $b.len()],
($a.asbytes(), $b.asbytes()) };
unsafe { $crate::transmute::<_, &'static str>(bytes) }
}};
($a:expr, $($rest:expr),*) => {{
const TAIL: &str = const_concat!($($rest),*);
const_concat!($a, TAIL)
}};
} ```
So first we create a &'static [u8] and then we transmute it to &'static str. This works for now because &[u8] and &str have the same layout, but it's not guaranteed to work forever. The cast to &'static [u8] works even though the right-hand side of that assignment is local to this scope because of something called "rvalue static promotion".
This currently doesn't work in trait associated constants. I do have a way to support trait associated constants but again, you can't access type parameters in array lengths so that unfortunately doesn't work. Finally, it requires quite a few nightly features:
```rust
```