http://d.puremagic.com/issues/show_bug.cgi?id=3789
--- Comment #15 from bearophile_h...@eml.cc 2012-03-26 04:30:41 PDT --- This is an answer to Walter to Bug 7783 : (In reply to comment #2) > In the absense of a user-defined opEquals for the struct, equality is defined > as a bitwise compare. This is working as expected. Not a bug. I agree, it's not a DMD implementation bug because here it's working as designed. But I have voted bug 3789 time ago because I consider this in top 15 of the design decisions to fix/change, because this is a large source of bugs, it's unnatural. D is designed to be safe on default. Not comparing the strings as strings in the following code breaks the Principle of least astonishment: struct Foo { string name; bool b; } void main() { auto a = Foo("foobar".idup, true); auto b = Foo("foobar".idup, true); assert(a == b); } For me the only acceptable alternative to fixing Bug 3789 is statically disallowing the equal operator (==) in such cases. D language has the "is" for the situations where you want to perform bitwise comparison of structs too. This is OK. For the other situations where I use "==" among struts, I want it do the right thing, like comparing its contained strings correctly instead of arbitrarily choosing bitwise comparison of the sub-struct that represents the string. Making "==" work as "is" for structs means using an operator for the purpose of the other operator, and it has caused some bugs in my code. And it will cause bugs in future D code. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------