On Tuesday, 30 October 2012 at 16:44:02 UTC, Ali Çehreli wrote:
There is the following discussion currently on the main D forum:
http://forum.dlang.org/thread/iphhuttpkogmfwpuv...@forum.dlang.org
That behavior will be changed:
http://forum.dlang.org/thread/iphhuttpkogmfwpuv...@forum.dlang.org?page=4#post-k6a30m:24140h:241:40digitalmars.com
Interesting, thanks! In reading this and (per Tobias' comment)
revisiting TDPL I think my original statement was incomplete and
the situation is not as bad as I thought.
For any struct S, '==' means either bitwise comparison or a
call to
opEquals of S if it exists.
From TDPL: Objects of struct type can be compared for equality
out of the box with == and ! =. Comparison is carried out member
by member and yields false if at least two corresponding members
in the compared objects are not equal, and true otherwise.
So the issue in my example is not a problem with structs in
general, but just a bug related to dynamic arrays only. My fear
of having to provide opEquals at each level is unwarranted - the
compiler will generate good ones for me (except for dynamic
arrays until the bug is fixed).
I've convinced myself of this in the following example.
http://dpaste.dzfl.pl/14649c64
So until this bug is fixed any time I have any dynamic array,
including string in struct S, implement opEquals. When the bug is
fixed I can remove them. What I didn't realize is that including
an opEquals in A will cause generation of opEquals in B,C,D for
free (maybe only if called).
If this is still off base please let me know.
Thanks
Dan
