[D-runtime] Two questions about object opEquals

[Jonathan M Davis]

On Saturday, March 09, 2013 21:00:07 Simen Kjærås wrote:
> On Sat, 09 Mar 2013 16:28:50 +0100, kenji hara <k.hara.pg at gmail.com> wrote:
> > I don't know why following. Can someone answer?
> > 
> > 1. Object.opEquals(Object lhs, Object.rhs)
> > 
> > It seems to me that nobody uses it. Why it exists?
> > 
> > 2. object.opEquals(TypeInfo lhs, TypeInfo rhs)
> > 
> > It might be used to hack for typeid(x) == typeid(y), but I'm not sure.
> > That is much ambiguous, and if it's really used, we should move it to
> > static TypeInfo.equals and explicitly use it by the name.
> > 
> > Kenji Hara
> 
> I might be misremembering, but I seem to recall objA == objB is rewritten
> into Object.opEquals(objA, objB). Object.opEquals(Object lhs, Object rhs)
> then does the actual two-way comparison of objA.opEquals(objB) &&
> objB.opEquals(objA).

I believe that that rewrite uses the free function opEquals in object_.d, and 
not the one on Object. To make matters even more bizarre, the one on Object 
isn't even static. I suspect that the one on Object can and should be axed. 
The way it's written is nonsensical, and AFAIK, it's never used.

Of course, the opEquals stuff does need to be revamped a bit anyway, since we'd 
decided that we want to move towards getting rid of opEquals, opCmp, toHash, 
and toString on Object, which in the case of opEquals means templatizing the 
opEquals free function and make it so that it doesn't use Object at all.

- Jonathan M Davis