[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