Built-in array opSliceAssign

[Stanislav Blinov]

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