Built-in array opSliceAssign

[Eduard Staniloiu]

On Thursday, 25 October 2018 at 13:01:06 UTC, Eduard Staniloiu 
wrote:
> On Thursday, 25 October 2018 at 12:38:44 UTC, Paul Backus wrote:
>> On Thursday, 25 October 2018 at 12:25:37 UTC, Eduard Staniloiu 
>> wrote:
>>> As I wrote in the comments above, I was expecting `a[] = b[]` 
>>> to iterate the slices and assign the elements of b into a.
>>>
>>> What really happens is a memcpy: as you can see from godblot 
>>> [0], this gets lowered to a call to `_d_arraycopy`, in 
>>> druntime.
>>
>> In D, when you assign one aggregate to another, opAssign is 
>> only called for the aggregate, not for any of its elements. 
>> However, postblit constructors are called for both. Example: 
>> https://run.dlang.io/is/XfDaWw
>>
>
> Can you, please, give me a link to where it says this in the 
> specs?
>
> Based on the example, I would expect that the code gets lowered 
> to some version of `_d_arrayassign` [0]. I still think that 
> this is problematic, as it's unexpected to the user: you're 
> expecting the assignment operator to be called, not the 
> postblit.
>
> I know that the compiler can and will create an opAssign if a 
> postblit or dtor is defined, as you can write the assignment as 
> a this._dtor; blit rhs into this.
>
> This being said, I think that if the user took the time to 
> define opAssign, it should be called, because he might want to 
> do something extra when an assignment occurs: an ex. having 
> different logs "creating new obj" vs "changing existing obj".
>
>
>> Your example will work as expected if you change the opAssign 
>> to a postblit constructor: https://run.dlang.io/is/HBbGO2

Accidentally sent to early.

One extra reason as to why, imho, this implicit call to the 
postblit is evil, is that a lot of code will probably break when 
we'll transition to the CopyConstructor. See RazvanN's PR [0].

This is actually how I stumbled upon this, as I am using his 
branch with my repo.

[0] - https://github.com/dlang/dmd/pull/8688