[dmd-beta] Fighting with 2.059 and not quite winning

[Jonathan M Davis]

On Sunday, April 08, 2012 02:15:42 Vladimir Panteleev wrote:
> On Sun, 08 Apr 2012 00:18:41 +0300, Vladimir Panteleev
> 
> <thecybershadow.lists at gmail.com> wrote:
> > I've hit the mysterious opEquals problem again (this time with nothrow
> > instead of pure). I'm going to try minimizing my codebase and find the
> > cause.
> 
> I found the problem. The cause is that Object's opEquals is not nothrow,
> another chicken-and-egg problem.
> 
> class C
> {
> 	override bool opEquals(Object o) const nothrow
> 	{
> 		return true;
> 	}
> }
> 
> struct S
> {
> 	C o;
> 
> 	bool opEquals(ref const S s) const nothrow
> 	{
> 		return o == s.o;
> 	}
> }
> 
> What's even worse, is that overriding Object's opEquals with a nothrow
> implementation still causes the error. I guess that's because a==b calls
> the free opEquals function from object.d, which is not nothrow.

Object's functions have been messed with much yet. toHash is the only one 
which has any attributes on it (@trusted and nothrow), and it doesn't have all 
of the ones that it's supposed to yet. I believe that toString, opEquals, 
opCmp, and toHash will all become @safe const pure nothrow in one sweep, which 
will break a _lot_ of code. But that transition hasn't been completed yet. 
Work was done on that this release, but it'll be completed for 2.060 at the 
earliest.

So, the situation with opEquals on classes should not have changed at all with 
this release. It's changed somewhat with structs ( 
http://d.puremagic.com/issues/show_bug.cgi?id=7833 ), but not classes. So, I 
wouldn't have expected your code to break due to anything related to opEquals 
and classes. Maybe something was changed in how attributes are dealt with on 
overridden functions though. That would affect opEquals along with every other 
overidden function.

- Jonathan M Davis