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
