On Friday, 25 July 2014 at 05:52:57 UTC, Manu via Digitalmars-d
wrote:
On 25 July 2014 14:50, Walter Bright via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
On 7/23/2014 9:45 AM, H. S. Teoh via Digitalmars-d wrote:
https://issues.dlang.org/show_bug.cgi?id=13179
Consider also:
http://www.reddit.com/r/programming/comments/2bl51j/
programming_in_d_a_great_online_book_for_learning/cj75gm9
The current scheme breaks existing code - code that was
formerly correct
and working.
AAs don't make sense if the notion of == on members is
invalid. AAs
formerly required opCmp, and yes, opCmp could be constructed
to give
different results for opCmp==0 than ==, but I would expect
such an object
to not be used in an AA, again because it doesn't make sense.
Using the default generated opEquals for AAs may break code,
such as the
an AA of the structs in the parent post, but it seems unlikely
that that
code was correct anyway in an AA (as it would give erratic
results).
Kenji's rebuttal
https://issues.dlang.org/show_bug.cgi?id=13179#c2 is
probably the best counter-argument, and I'd go with it if it
didn't result
in code breakage.
I don't really see how opCmp == 0 could be unreliable or
unintended. It was
deliberately written by the author, so definitely not
unintended, and I
can't imagine anybody would ever deliberately ignore the == 0
case when
implementing an opCmp, or produce logic that works for less or
greater, but
fails for equal.
<= and >= are expressed by opCmp, which imply that testing for
equality
definitely works as the user intended.
In lieu of an opEquals, how can a deliberately implemented
opCmp, which we
know works in the == case (otherwise <= or >= wouldn't work
either) ever be
a worse choice than an implicitly generated opEquals?
Personally, just skimming through this thread, I find it
baffling that this
is controversial.
So, in the case where opCmp was defined but not opEquals, instead
of using the normal, built-in opEquals (which should already be
equivalent to lhs.opCmp(rhs) == 0), we're going to make the
compiler generate opEquals as lhs.opCmp(rhs) == 0? That's a
silent performance hit for no good reason IMHO. It doesn't even
improve correctness except in the cases where the programmer
should have been defining opEquals in the first place, because
lhs.opCmp(rhs) == 0 wasn't equivalent to the compiler-generate
opEquals. So, we'd be making good code worse just to try and fix
an existing bug in bad code in order to do what? Not break the
already broken code?
I can understand wanting to avoid breaking code when changing
from using opCmp to using opEquals with AAs, but it's only an
issue if the code was already broken by defining opCmp in a way
that didn't match opEquals, so if I find it odd that any part of
this is controversial, it's the fact that anyone thinks that we
should try and avoid breaking code where opEquals and opCmp
weren't equivalent.
- Jonathan M Davis
