How about some __initialize magic?

[kinke]

On Saturday, 27 November 2021 at 21:56:05 UTC, Stanislav Blinov 
wrote:
> [...]
> Upcoming `__traits(initSymbol)` would help in removing the hack,

It's already removed in master.

> but won't help CTFE any. At various points of their lives, 
> these things even explicitly called `memcpy`, which is just... 
> argh! And some still do (`copyEmplace`, I'm looking at you). 
> Call into CRT to blit a 8-byte struct? With statically known 
> size and alignment? Just to sidestep type system? Eh???

1. Most optimizers recognize a memcmp call and its semantics, and 
try to avoid the lib call accordingly.
2. A slice copy (`source[] = target[]` with e.g. void[]-typed 
slices) is a memcpy with additional potential checks for matching 
length and no overlap (with enabled bounds checks IIRC), so 
memcpy avoids that overhead. It also works with -betterC; e.g., 
the aforementioned checks are implemented as a druntime helper 
function for LDC and so not available with -betterC.
3. I haven't checked, but if memcpy is the only real CTFE blocker 
for emplace at the moment, I guess one option would be extending 
the CTFE interpreter by a memcpy builtin, in order not to have to 
further uglify the existing library code.

> What do you think? DIP this, yay or nay? Suggestions?..

I'm not convinced I'm afraid. :) - I've been thinking in the 
other direction, treating core.lifetime.{move,forward} as 
builtins for codegen (possibly restricted to function call 
argument expressions), in order to save work for the optimizer 
and less bloat for debug builds.