[Issue 3789] Structs members that require non-bitwise comparison not correctly compared

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=3789


Jonathan M Davis <jmdavisProg at gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg at gmx.com


--- Comment #21 from Jonathan M Davis <jmdavisProg at gmx.com> 2012-10-27 19:52:35 PDT ---
I just thought that I should point out that the correct behavior for comparing
structs is explained in section of 7.1.5.2 of TDPL (p. 258 - 259). It doesn't
explicitly discuss what happens with built-ins (it says that opEquals is called
on each of the members), but I would think that calling opEquals on each of the
members would mean using == on built-in types and _not_ bitwise comparison. So,
I think that it's pretty clear that the correct behavior is that the default
behavior of opEquals for a struct like

struct S
{
    T t;
    U u;
}

mean that the compiler generates an opEquals like (ignoring the issues with the
refness or constness of the argument or opEquals itself):

bool opEquals(S rhs)
{
    return t == rhs.t && u == rhs.u;
}

and that the types of T and U are completely irrelevant. If the compiler wants
to optimize it to being a bitwise comparison when that would result in exactly
the same behavior (save for performance differences), then great, but it should
_never_ do bitwise comparison when that would result in different semantics
from using == on each of the members.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------