• Teodor Dutu (18/18) Oct 30 2021 Hi,

Teodor Dutu <teodor.dutu gmail.com> writes:

Hi,

This week I made some progress with regards to the conversion of 
`_d_arrayappendcTX` from using a hook to a template. This week I 
doubled back on last week's decision to replace [this 
`assert`](https://github.com/dlang/dmd/blob/a890f134af71c553d74ea346650cdea1d2e5f0ad/src/dmd/dinte
pret.d#L5038-L5041) in order to convert the call to `_d_arrayappendcTX(ea, eb)`
to `ea.length += 1`. Razvan and I reached this decision based on [these
comments](https://github.com/dlang/dmd/pull/9982/files#r310356331). They showed
us that Dan's initial implementation was actually correct in lowering `a ~= b`
to `__ctfe ? a ~= b : _d_arrayappendcTX(a, 1), a[$ - 1] = b, a;` 
and not just to the latter comma expression.

The reason for this particular lowering is so that dinterpret.d 
is can use `__ctfe` to interpret `a ~= b` as a whole. Moreover, 
during the inline phase, this conditional expression is replaced 
with an equivalent `if - else` statement. This also passes the `a 
~= b` branch to be backend, which triggered [this 
asert](https://github.com/dlang/dmd/blob/a890f134af71c553d74ea346650cdea1d2e5f0ad/sr
/dmd/e2ir.d#L3297). So the solution was to remove the `if` body and only keep
the `else` body in s2ir.d.

In the meantime, I've also been working on changing 
`_d_arrayctor`'s 
[signature](https://github.com/dlang/druntime/blob/20963f956c550b7b1b52849e5cf41f436d0df788/src/core/internal/array
construction.d#L24) so that it creates and returns the destination array,
instead of receiving and modifying it as a parameter. This is meant to prevent
warnings whereby the function is perceived by the compiler as strongly pure,
while its return value is ignored. I've made some progress, but my current
implementation allocates the new array dynamically. Thus, it doesn't make use
of NRVO yet and the returned array has to be copied back to its intended
destination.

Thanks,
Teodor