[Issue 13179] AA key type TagIndex now requires equality rather than comparison
via Digitalmars-d-bugs
digitalmars-d-bugs at puremagic.com
Wed Jul 23 09:40:07 PDT 2014
https://issues.dlang.org/show_bug.cgi?id=13179
hsteoh at quickfur.ath.cx changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |---
--- Comment #8 from hsteoh at quickfur.ath.cx ---
(In reply to Kenji Hara from comment #7)
[...]
> But currently `a == b` is never rewritten to `a.opCmp(b) == 0`. It's in a
> domain of enhancement request that requires more discussion.
Wait, wat?? That's ridiculous... I think this is a bug. If I define opCmp, then
a==b should work even if I don't define opEquals. Otherwise this leads to the
current ridiculous situation:
------
struct S {
int x;
int y;
int opCmp(S s) {
return x - s.x;
}
}
void main() {
auto s1 = S(1,2);
auto s2 = S(1,3);
auto s3 = S(2,1);
assert(s1 < s3); // OK
assert(s2 < s3); // OK
assert(s3 > s1); // OK
assert(s3 > s2); // OK
assert(s1 <= s2 && s2 >= s1); // OK
assert(s1 == s2); // FAIL
}
------
The last two lines show that s1<=s2 && s1>=s2 does not imply s1==s2. I find
that difficult to accept. I think this needs to be fixed.
> (In reply to hsteoh from comment #4)
> > By your logic, the compiler should reject "a == b" when the programmer
> > hasn't defined opEquals, because the compiler cannot know whether
> > a.opCmp(b)==0 is what the programmer is expecting. I don't understand how
> > this could make any sense.
>
> It's not a logic issue. If opCmp is defined and `a == b` will be
> automatically rewritten to `a.opCmp(b) == 0`, the code behavior will be
> _silently_ changed.
>
> So compiler reports a diagnostic error. It's far better than silent changing.
I think that any code depends on the fact that s1<=s2 && s1>=s2 doesn't imply
s1==s2, is already horribly broken.
--
More information about the Digitalmars-d-bugs
mailing list