On Thu, Jul 24, 2014 at 08:36:02PM +0000, Jonathan M Davis via Digitalmars-d wrote: > On Thursday, 24 July 2014 at 19:35:12 UTC, Andrei Alexandrescu wrote: > >I like Daniel's idea to auto-define opEquals as a field-for-field > >comparison. -- Andrei
Isn't that what the compiler already does? > That's basically what the compiler-generated opEquals does (though I > think that it'll just to a memcmp if it knows that it can get away > with that). So, if that's what you want, you're arguing for just have > the compiler still define opEquals for you even if opCmp is defined. > And I'm fine with that, but if the concern is code breakage for AAs, > and opCmp is not defined in a way that's consistent with opEquals, > then that would break them. Now, I think that such types are buggy, so > I'm not sure that that's all that big a deal, but if I understand > correctly, basically anything that we do with 2.066 which doesn't > involve continuing to use lhs.opCmp(rhs) == 0 for the AAs will break > them, and we need to change it to use opEquals, so I'm not sure that > we _can_ avoid code breakage unless the type defines opEquals, and it > defines it in a manner which is consistent with opCmp (which it > _should_ do but might not). And if that's the case, then it just comes > down to what type of code breakage we want to incur. And IMHO, having > the default opEquals continue to be generated when opCmp is defined is > a very workable solution, since no types should have defined opCmp in > a way that was inconsistent with opEquals. [...] Keep in mind that the last sentence means that wrong code (i.e. inconsistent opCmp/opEquals) will silently compile and misbehave at runtime. T -- Answer: Because it breaks the logical sequence of discussion. Question: Why is top posting bad?