A fresh look at comparisons

[Bruce Adams]

On Tue, 15 Apr 2008 07:49:21 +0100, Janice Caron <caron800 at googlemail.com>  
wrote:

> On 15/04/2008, Scott S. McCoy <tag at cpan.org> wrote:
>
>>  Can you say definitively and for certain that in all
>>  environments in all programs ever written in D, that an object of type  
>> A
>>  and an object of type B will never be equal even though they have no
>>  common ancestor?
>
> No, so obviously you're right, and we would need to make it
> overloadable, as per the above example.
>
>
>>  And also, we cannot say that for instance, if you have types B and C
>>  which are both descendants of type A, that you will want B to be equal
>>  to C if A.opEquals() returns true for the two instances.
>
> You're right, and that's one thing I don't like about opEquals, and
> which is(==) would solve. So, under the revised proposal:
>
>     class A
>     {
>         is(this == c) {...}
>     }
>
>     class B : A {}
>     class C : A {}
>
>     B b;
>     C c;
>
>     if (b == c) ...
>
> This test would now have to return false always, because the new rules
> must compare B with B, or C with C, and must /not/ cast b and c to
> their common type.

I don't think even this is safe. The normal definition of inheritance is  
that
you can use B or C wherever you could use an A. Its probably safe that it  
doesn't
compile by default.

> Under the new rules, to compare B with C, the
> programmer would now have to write
>
>     class B : A
>     {
>         is(this == C c) {...}
>     }
>
>     class C : A
>     {
>         is(this == B b) {...}
>     }
>
> I think that covers all the edge cases that people have pointed out.
> With that adjustment, the scheme, I think, now works a treat.
>
Yes. The semantics are there. We just need to find a syntax that fits  
better with D.
This doesn't quite sit right when everything else is an Op-something.

Regards,

Bruce.