Choosing an Approach for the Template Lowering of _d_arrayctor

[Stanislav Blinov]

On Friday, 26 November 2021 at 14:58:04 UTC, kinke wrote:
> On Friday, 26 November 2021 at 11:59:37 UTC, Stanislav Blinov 
> wrote:
>> On Friday, 26 November 2021 at 02:42:23 UTC, kinke wrote:
>>> Note that this is exactly the current behavior of 
>>> intimately-related .dup for non-POD slices: 
>>> https://github.com/dlang/druntime/blob/595707b1ac8a439b2a7243b0abf95d4bc56239ff/src/object.d#L3601-L3627
>>
>> https://issues.dlang.org/show_bug.cgi?id=22547
>
> Thanks for filing. What I wanted to get at is that there seems 
> to be a need for a `copyEmplaceArray(S, T)(S[] source, T[] 
> target)`, which can be used for _d_arrayctor, dup and 
> copyEmplace (for static arrays). copyEmplace for static arrays 
> currently handles throwing copies in yet another way 
> (https://github.com/dlang/druntime/blob/595707b1ac8a439b2a7243b0abf95d4bc56239ff/src/core/lifetime.d#L1266-L1285), but that's already filed: https://issues.dlang.org/show_bug.cgi?id=22177
>
> With copyEmplaceArray, _d_arrayctor could keep on 
> stack-allocating the static array result and returning it via 
> NRVO.

I've left some thoughts on that in the bug tracker.

As for making a generic utility - absolutely agree. However, it 
does require an upgrade for `copyEmplace` - it __has__ to be made 
to work in CTFE, which it currently doesn't due to the way it 
blits. If `_d_arrayctor` is to be made a lowering for array 
initialization, **and** involve `copyEmplace`, we need it to work 
at compile time. `.dup` can (and does) work around it trivially, 
but `_d_arrayctor` wouldn't be able to.