On Monday, 5 November 2012 at 18:53:20 UTC, Tobias Pankrath wrote:
I like the general style. However this provokes a invinite loop:
Good catch. Fixed. There may be more complex scenarios of nested locking references that cause similar loop.
And I would find the comparison more useful, if it uses the user defined opEquals for a field if there is one.
Good point, this could be changed easily enough. The point for OpEquals was to use this for the issues pointed out in the thread. A benefit of just always using typesDeepEqual within typesDeepEqual is if I forget a mixin(OpEquals) in some class A, agreggated in some B, I'm still covered. So, below my deep equals works as expected for B even though A has no suitable opEquals. I think this should work even if I do not own A, which is a plus. The downside is if there is a custom opEquals for a struct that is more efficient it wont get called.
As bearophile pointed out this issue will change anyway. At that point I think the OpEquals becomes mute. I hope I'm covered by just turning its implementation into a no-op and my classes don't change.
Thanks Dan -------------- struct A { void pushOne() { i ~= 1; } private: int[] i; } struct B { mixin(OpEquals); A a; } void main() { A a1, a2; a1.pushOne(); a2.pushOne(); B b1 = {a1}, b2 = {a2}; writeln(a1==a2); // false writeln(b1==b2); // true }