Does anyone understand: https://issues.dlang.org/show_bug.cgi?id=19598 And are there any known workarounds?

On Monday, 21 January 2019 at 00:44:02 UTC, Manu wrote:
> Does anyone understand: https://issues.dlang.org/show_bug.cgi?id=19598 And are there any known workarounds?

Defining an opAssign for S seems to work:

int test()
{
    struct S { int x; void opAssign(S s) { x = s.x; } }
    S t1;
    S* n1 = new S;
    *n1 = t1;

    return 10;
}
pragma(msg, test());

Fascinatingly, it seems 'new' is doing something special in this code - replacing 'new S' with '&t1', things compile.

Second workaround: create an array of S, then take the address of the first one:

int test2()
{
    struct S { int x;  }
    S t1;
    S* n1 = &(new S[1])[0];
    *n1 = t1;

    return 10;
}
pragma(msg, test2());

Now, as for why the simple, sensible code in the bug report doesn't work, I have no idea. It seems `new S` marks the block in some way that prevents regular assignment from working.

--
  Simen

On Monday, 21 January 2019 at 07:31:39 UTC, Simen Kjærås wrote:
> Now, as for why the simple, sensible code in the bug report doesn't work, I have no idea. It seems `new S` marks the block in some way that prevents regular assignment from working.

So I spent a little time looking into this. It seems assignToLvalue doesn't know how to deal with structs. I simply added this to dinterpret.d, around line 4026 (just before the "`%s` cannot be evaluated at compile time" block):

        else if (auto sle = e1.isStructLiteralExp())
        {
            oldval = sle;
        }

Now, is this a sufficient fix? I don't know. Does it break things elsewhere? I don't know. Does it work in this specific case, solving this specific problem? Sure does.

--
  Simen