dmd 1.057 and 2.041 release

[Steven Schveighoffer]

On Mon, 08 Mar 2010 01:54:12 -0500, Walter Bright  
<newshound1 at digitalmars.com> wrote:

> Lots of meat and potatoes here, and a cookie! (spelling checker for  
> error messages)
>
> http://www.digitalmars.com/d/1.0/changelog.html
> http://ftp.digitalmars.com/dmd.1.057.zip
>
>
> http://www.digitalmars.com/d/2.0/changelog.html
> http://ftp.digitalmars.com/dmd.2.041.zip
>
> Thanks to the many people who contributed to this update!

This might belong on d.learn, but it's so specific to this release, I'll  
ask here:

The implementation of opEquals(Object, Object) contains the following  
implementation (according to docs and source):

bool opEquals(Object a, Object b) {
     if (a is b) return true;
     if (a is null || b is null) return false;
     if (typeid(a) == typeid(b)) return a.opEquals(b);
     return a.opEquals(b) && b.opEquals(a);
}

The third line seems to be a recursive call into opEquals, since the  
typeinfos are objects.  But because the two typeid classes have the same  
typeinfo (TypeInfo_Class with class name "TypeInfo_Class") it will only go  
2 levels deep since the first if clause will be true.  However, it seems a  
bit redundant to verify that the typeids are not null (they will always be  
non-null) and have the same typeinfo (they will).

Wouldn't it be more efficient and correct to just do:

if(typeid(a).opEquals(typeid(b)))

Also, there is a function inside object implementation to compare two  
typeinfos (commented out in interface file), is that used?  Does the  
compiler allow overloading the global opEquals?

Also, const is not respected:

class C
{
    int x;
    bool opEquals(Object other){ ++x; return false;}
}
void main()
{
    const c = new C;
    const d = new D;
    assert(c != d);
}

compiles without complaint.  I would argue that opEquals should be const  
in both Object and the global function, but I'm not sure of the  
ramifications.  At the very least, the above should not compile.

-Steve