Can I call the default opAssign after overloading opAssign?

[Rob T]

On Monday, 19 November 2012 at 06:32:56 UTC, Jonathan M Davis 
wrote:
> I'm not sure. Close certainly. But if any member variables 
> define an opAssign,
> then the compiler probably calls them rather than doing a 
> simple memcpy. I'm
> not sure though. If it does, then a memcpy would not exhibit 
> the same
> behavior, and the only way to get the same behavior would be to 
> copy each
> member variable one by one. If it doesn't, then a memcpy would 
> do the same
> thing as the default behavior.

I think you are right. There's was a post a couple days ago on an 
issue concerning a nested struct with opAssign. The parent had no 
opAssign, but the nested struct did, and for some reason the 
nested opAssign was not being called in one case, but was being 
called in another. Something about being relocatable?

> I am a bit worried though as to why you'd even want to skip 
> opAssign like
> that. At the moment, I can't think of any legitimate use cases 
> for doing that
> (though that obviously doesn't mean that you don't have one).
>
> - Jonathan M Davis

No reason I can see at this time either. I just want to fully 
understand what D is doing because it's not clearly documented. 
What worries me most, is if I end up relying on behaviors that 
end up being implemented as clever compiler optimizations rather 
than being a part of the D language specification (which is 
currently MIA).

--rt