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
