On Sunday, April 08, 2012 02:15:42 Vladimir Panteleev wrote: > On Sun, 08 Apr 2012 00:18:41 +0300, Vladimir Panteleev > > <[email protected]> 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 _______________________________________________ dmd-beta mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-beta
