On Thursday, 25 October 2018 at 13:22:36 UTC, Eduard Staniloiu
wrote:
The spec doesn't exactly say it uses memset, but it does imply
it:
https://dlang.org/spec/arrays.html#array-copying
talking about "aggressive parallel code optimizations than
possible with the serial semantics of C" and "copying" rather
than "assigned" etc.
but indeed postblit lets this work.
You are right. Thank you!
I guess I never read/understood it like this.
I expected it to use opAssign as that is what's the most
natural and intuitive decision for me.
I take it that this is the expected behaviour, then.
I don't think interpreting the spec like that is correct. It says
"...it means that the *contents* of the array are the target of
the *assignment*...", and further, in the examples:
s[1..2] = t[0..1]; // same as s[1] = t[0]
s[0..2] = t[1..3]; // same as s[0] = t[1], s[1] = t[2]
The current behavior of the compiler is quite the opposite of
those "same as" above.
Consider:
struct S {
@disable this(this); // can't implicitly copy, i.e. pass
lvalue to a function
void opAssign(ref S rhs) { /* ... */ } // but can explicitly
copy
}
void main() {
S x, y;
x = y; // works
S[10] a;
a[0 .. 3] = y; // doesn't compile, i.e. NOT "same as
a[0] = y, a[1] = y, a[2] = y"
a[0 .. 3] = a[3 .. 6]; // doesn't compile either, i.e. NOT
"same as a[0] = a[3], a[1] = a[4], a[2] = a[5]"
}
I've filed an issue about this around a month ago:
https://issues.dlang.org/show_bug.cgi?id=19274
