On Sunday, 3 September 2023 at 05:52:12 UTC, Walter Bright wrote:
> String concatenation tends to be highly useful in CTFE code, and runtime performance considerations don't exist.

Well, it depends there too since CTFE string concat has absolutely terrible performance if you do a lot of it.

A small x ~ y in CTFE is virtually invisible, I'd be fine with that. But a loop of string ~= thing in ctfe quickly becomes a compile time killer - it is at least quadratic time.

Redoing that as a single pre-allocated char[] that is slice assigned can take very noticeable times off builds. For example, my jsvar.d used to have one that ballooned builds to about 6 seconds. I rewrote it with a length calculation loop, single allocation, slice assign loop instead of a ~= loop, and it brought it back down to 2 seconds. (Still a bit slow, but obviously 2 is much faster than 6.)

Or my jni.d when running over android, it used to use a CTFE string.replace and it took *minutes* to compile along with dozens of gigabytes of ram.  Prerunning that, so it was just two separate string literals (yes, this ctfe use only ended up in two permutations when all was said and done) brought that back to the land of reality too.

So CTFE concat I almost think is *more* dangerous than runtime concat. At least the runtime concat has *consistently* decent performance.

That said tho, anybody reading this, if your strings are short, CTFE concat works perfectly well. Don't overcomplicate code unless the strings are long and there's an append loop, then you MIGHT notice the difference.