Lowerings to strongly pure _d_arrayctor trigger warnings or risk being incorrectly removed
teodor.dutu at gmail.com
Tue Oct 12 19:31:34 UTC 2021
On Tuesday, 12 October 2021 at 18:27:53 UTC, Paul Backus wrote:
> On Tuesday, 12 October 2021 at 18:04:21 UTC, Teodor Dutu wrote:
>> I have read the documentation at the links you left, but I
>> can't see why the usage of `_d_arrayctor` would be an
>> undefined behaviour.
> `_d_arrayctor` casts away `immutable` internally--either
> [here], directly, or [here] indirectly via `copyEmplace`
> (which casts it away [here]). It then uses `memcpy` to
> mutate the memory that was originally typed as `immutable`.
> This is undefined behavior, according to the language spec.
>> This lowering only occurs when initialising static arrays or
> The spec does not currently make an exception for initializing
> static arrays or slices, so the fact that it only occurs in
> that context does not make any difference to whether the spec
> considers it UB.
I see your point now. But this behaviour is not new. The current
implementation uses [this
hook](https://github.com/dlang/druntime/blob/a17bb23b418405e1ce8e4a317651039758013f39/src/rt/arrayassign.d#L170), which suffers from the same shortcomings. Furthermore, the hook uses `TypeInfo`, which makes it slower than what I'm trying to achieve with the templated approach.
And secondly, bear in mind that the lowering only occurs when the
`lhs` is being constructed, which means that two things can
- the compiler can perform constant propagation by replacing the
`rhs` variable with an array literal, which will **not** be
lowered to `_d_arrayctor`:
- the compiler doesn't perform this optimisation, which means
that some data has to be written into the `const`/`immutable`
I don't see how the second scenario can be avoided, with or
More information about the Digitalmars-d