Appending Lvalues will give the same result even though it should
be disabled.
Comment #2 by lovelydear — 2012-04-20T02:10:02Z
Not sure I did the right thing, but I can't reproduce the error on Win32 2.059
Comment #3 by verylonglogin.reg — 2012-07-02T03:15:53Z
There is no linker/assert error any more. Once postblit is disabled it just silently not called. Very nasty.
Comment #4 by verylonglogin.reg — 2012-07-02T03:29:39Z
This compiles and runs successfully:
---
struct Foo
{
// postblit can also have no body because isn't called
@disable this(this) { assert(0); }
}
void main()
{
Foo[3] sarr1, sarr2;
sarr2 = sarr1;
Foo[] darr1 = new Foo[3], darr2 = new Foo[3];
darr2[] = darr1[];
Foo s;
darr1 ~= s;
darr1 = darr1 ~ s ~ darr2;
}
---
Comment #5 by k.hara.pg — 2012-07-07T08:01:15Z
(In reply to comment #1)
> Appending Lvalues will give the same result even though it should
> be disabled.
Even if the array element is a struct has disabled postblit, the concatinations and appendings should be rejected statically by the compiler.
struct S
{
// postblit can also have no body because isn't called
@disable this(this) { assert(0); }
}
void main()
{
S[] da;
S s;
da ~= s; // 1. appending lvalue requires copying.
da ~= S(); // 2. appending rvalue *also* requires copying
}
Why #2 should be rejected? Because, it might runs copying by the runtime...
S[] da1 = new S[](3);
S[] da2 = da1[0..1];
assert(da2.capacity == 0);
da2 = S(); // appending rvalue!
assert(&da1[0] !is &da2[0]);
// da1[0] is _copied_ by the runtime implicitly, but it breaks the
// guarantees of the @disable postblit.
Therefore, we should reject *all* concatenation and appending of an array of structs that has disabled postblit.
Comment #6 by github-bugzilla — 2012-08-21T05:04:48Z