Jonathan M Davis wrote: > On Friday, October 26, 2012 19:46:16 deadalnix wrote: > > Le 25/10/2012 04:12, Jonathan M Davis a écrit : > > > On Wednesday, October 24, 2012 13:31:14 Walter Bright wrote: > > >> The default compare for structs is a bit compare of the contents. > > > > > > Which definitely seems inherently broken. Doing that only works if the > > > struct only contains integral types, character types, or bool. Nothing > > > else will compare properly that way. It really needs to work like arrays > > > do (or are supposed to anyway) and compare each member according to == > > > and only fallback to an outright bitwise compare when it knows that the > > > results would be identical (i.e. because all of the members are integral > > > types, character types, bool, or other structs which hold only integral > > > types, character types, or bool - be it directly or in other structs that > > > they hold). Bitwise comparison is the is operator's job, not ==. > > > > > > - Jonathan M Davis > > > > That will broke code. > > > > But That is the way to go IMO. D needs to evolve to make things more > > consistent in general. > > > > Still not doable without a proper versionning scheme. > > TDPL clearly states that each of the struct's members are supposed to be > checked for equality (see section 7.1.5.2, p. 258 - 259). It's outright a bug > for structs to be checked for equality with a bitwise comparison when the > bitwise comparison does not do exactly what == would have done had each and > every member variable been compared with ==. And as with all bugs, fixing it > could break code which depends on the buggy behavior. But given the nature of > this bug, I seriously question that much of anyone thought that the == on > structs was supposed to do anything other than what TDPL states that it > should > and that pretty much no one was expecting it to do a bitwise comparison. So, > if anything, this will _fix_ far more code than it breaks.
I was looking for that section. 3789 is clearly a bug and should be fixed as soon as possible. Votes indicate how important a bug should be. But duplicates are also a good indicator. This bug has six duplicates. Jens