[Issue 21312] [REG 2.095] Newly triggered <expr> is not an lvalue and cannot be modified

d-bugmail at puremagic.com d-bugmail at puremagic.com
Fri Oct 16 06:40:29 UTC 2020


https://issues.dlang.org/show_bug.cgi?id=21312

--- Comment #2 from Mathias LANG <pro.mathias.lang at gmail.com> ---
> So if looks like you are using `&[foo()][0]` to get around the fact that call expressions aren't lvalues (e.g: `&foo()`).

The code is in a deserializer. We handle pointers as single-entry arrays, and
the code follow that pattern. It recurses into itself, deserialize a single
entry of whatever the element type is, and use this to build an array. It then
takes the `.ptr` of this array.
It is no different in its intent from:
```
E[] result = [ deserializeFull!(...)(...) ];
return result.ptr;
```
Except that `result.ptr` is not `@safe`, so I'd have to use `return
&result[0];`, but was hoping to avoid bounds checking by putting the expression
inline.

> 1. There's nothing to prevent the optimizer removing the `[ ][0]` as being redundant.

`[][0]` might be redundant, but `&[][0]` is not, given `[]` does GC allocation.

> 2. There's nothing to prevent the array literal being stack allocated.

The compiler shouldn't promote it to the stack if it can't prove the address
isn't escaping, which it is here.

--


More information about the Digitalmars-d-bugs mailing list