http://d.puremagic.com/issues/show_bug.cgi?id=3789
Jonathan M Davis <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #21 from Jonathan M Davis <[email protected]> 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: -------
